InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/ccitt/1988/troff/7_2_04.tro

Text File | 1991-12-13 | 172KB | 7,262 lines

.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\"                 Not Copyright ( c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P

.rs
\v | 5i'
.sp 1P
.ce 1000
\v'3P'
SECTION\ 6
.ce 0
.sp 1P
.ce 1000
\fBRADIOTELEX\ INTERWORKING\fR \v'1P'
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ U.60\fR
.RT
.sp 2P
.ce 1000
\fBGENERAL\ REQUIREMENTS\ TO\ BE\ MET\ IN\ INTERFACING\ THE\ INTERNATIONAL\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.60''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.60    %'
.ce 0
.sp 1P
.ce 1000
\fBTELEX\ NETWORK\ WITH\ MARITIME\ SATELLITE\ SYSTEMS\fR
.ce 0
.sp 1P
.ce 1000
\fI(Geneva, 1980; amended at Malaga\(hyTorremolinos, 1984)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that, with fully automatic working between subscribers   in
the international telex service, it is desirable that the interface between
the international telex network and maritime satellite systems be defined;
.PP
(b)
that the CCIR is charged with the task of making
Recommendations relating to the radio path of maritime satellite systems;
.PP
(c)
that explanation of the detail of the interface between the international
telex network and maritime satellite systems would be of
assistance to the CCIR;
.PP
(d)
that Recommendation U.61 specifies the detailed
interface requirements,
.sp 1P
.LP
\fIunanimously recommends\fR
.sp 9p
.RT
.PP
(1)
that maritime satellite systems should be capable of
interfacing the
international telex network with one or more signalling systems in accordance
with:
.LP
    \(em
    Recommendation\ U.1:\ Signalling conditions to be applied in
the international telex service (type\ A and type\ B signalling);
.LP
    \(em
    Recommendation\ U.11:\ Telex and gentex signalling on
intercontinental circuits used for intercontinental automatic
transit traffic (type\ C signalling);
.LP
    \(em
     Recommendation\ U.12:\ Terminal and transit control signalling system
for telex and similar services on international circuits
(type\ D signalling);
.PP
(2)
that type D signalling (Recommendation U.12) and, as
a second choice,
type\ C signalling (Recommendation\ U.11) are the preferred signalling
systems, when they are available within the national boundaries, for the
reasons given in Annex\ A;
.PP
(3)
that as the maritime signalling from the ship to the
coast earth
station is in the same relationship as the connection from the subscriber to
the originating exchange in the international network, it is necessary that
the transit delays inherent in the maritime system should be considered in
conjunction with the standards recommended for the international
network.
.PP
(4)
that the access of ship earth stations to
store\(hyand\(hyforward
units, if provided, should be in accordance with the relevant Series\ F and\ U
Recommendations on international store\(hyand\(hyforward units.
.bp
.ce 1000
ANNEX\ A
.ce 0
.sp 1P
.ce 1000
(to Recommendation U.60)
.sp 9p
.RT
.ce 0
.sp 1P
.ce 1000
\fBSignalling systems types C and D\fR
.sp 1P
.RT
.ce 0
.PP
A.1
These signalling systems have been developed in CCITT to
permit the
maximum utilization of the international telex network as well as to simplify
the interface problems that exist between Administrations using different
signalling systems within their national boundaries. In particular,
types\ C and\ D signalling systems, which use telex destination codes in
accordance with
Recommendation\ F.69\ [1], are of assistance in solving the problems of
routing to and
from maritime satellite systems where multiple access techniques are
employed.
.sp 1P
.RT
.PP
A.2
Type C signalling (Recommendation U.11) facilitates the use of improved
techniques for switching traffic in the international network. In
particular:
.sp 9p
.RT
.LP
    a)
    it permits any telegraph circuit capable of carrying
International
Telegraph Alphabet No.\ 2 (ITA\ 2) to be used without the need to convert
supervisory signals to a form capable of being carried by the circuit;
.LP
    b)
    it permits the automatic testing of the ability of the
international circuit to transmit teleprinter characters before the call is
established to the distant subscriber;
.LP
    c)
    it permits the detection of head\(hyon collision of calls and   thus
permits service protocols to be established in handling such collisions.
It may be noted that head\(hyon collisions may occur on telegraph circuits
that are
operated in the bothway mode due to the fact that the calling signal takes a
finite time, depending upon the nature of the transmission path, before the
receiving end of the circuit detects the seizure from the outgoing end;
.LP
    d)
    it permits the efficient use of the international network
with particular reference to the most economical use of automatic alternative
routing and, by providing transit centre identification, permits full
flexibility in routing as well as international accounting and subscriber
billing.
.PP
A.3
Type D signalling (Recommendation U.12) facilitates the
introduction
into the international network of the following facilities (in addition
to the advantages mentioned in \(sc\ A.2 above):
.sp 9p
.RT
.LP
    a)
    user groups;
.LP
    b)
    network identification signals;
.LP
    c)
     identification of the calling station without the necessity of using
the WRU signal;
.LP
    d)
     identification of a call relating to service matters, which the international
network carries as a non\(hychargeable call.
.sp 2P
.LP
    \fBReference\fR
.sp 1P
.RT
.LP
[1]
    CCITT Recommendation \fIPlan for telex destination codes\fR ,
Rec.\ F.69.
.sp 2P
.LP
\fBRecommendation\ U.61\fR
.RT
.sp 2P
.ce 1000
\fBDETAILED\ REQUIREMENTS\ TO\ BE\ MET\ IN\ INTERFACING\ THE\ INTERNATIONAL\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.61''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.61    %'
.ce 0
.sp 1P
.ce 1000
\fBTELEX\ NETWORK\ WITH\ MARITIME\ SATELLITE\ SYSTEMS\fR
.ce 0
.sp 1P
.ce 1000
\fI(Geneva, 1980; amended at Malaga\(hyTorremolinos, 1984)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.sp 2P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that fully automatic working between subscribers in the international telex
service and subscribers to a radiotelex service provided by a maritime
satellite system is technically possible;
.PP
(b)
Recommendation U.60, which gives the general
requirements to
be met in interfacing the international telex network with maritime satellite
systems,
.bp
.sp 1P
.LP
\fIunanimously recommends\fR
.sp 9p
.RT
.PP
\fB1\fR
Maritime satellite systems should be capable of detecting
the head\(hyon collision condition at the coast earth station between a
ship earth station request for call and a terrestrially originated call
for that
particular ship earth station and should:
.sp 9p
.RT
.LP
    \(em
    permit the ship\(hyoriginated call to be connected to the
international telex network; and
.LP
    \(em
    terminate the call from the international telex network
with an appropriate telex service signal\ (\fBOCC\fR ) and a clear
(Recommendation\ F.60\ [1]).
.PP
\fB2\fR
Should the head\(hyon collision condition occur in the
connections
in the terrestrial network between the coast earth station and the telex
exchange, then the normal procedures in accordance with the appropriate
Series\ U Recommendations (U.12, \(sc\ 3.3, U.11,\ \(sc\ 2, U.1 \(sc\ 12.2)
should prevail.
.sp 9p
.RT
.PP
\fB3\fR
A call\(hyconnected signal or a telex service
signal and clear shall be returned as soon as possible after the receipt
of the end\(hyof\(hyselection character at the coast earth station for
shore\(hyoriginated
calls. The signal return delay shall not exceed 35\ seconds.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ For type C signalling (Recommendation U.11) the
end\(hyof\(hyselection (EOS) character is combination No.\ 26\ (\fB+\fR
) in International Telegraph Alphabet No.\ 2. For type\ D signalling (Recommendation\
U.12) the EOS is character No.\ 11 in the Control Signalling Code\ (CSC).
For signalling to Recommendation\ U.1, this signal shall be combination
No.\ 26\ (\fB+\fR ) in
International Telegraph Alphabet No.\ 2.
.PP
\fB4\fR
The maritime satellite system returns to the subscriber in
the
terrestrial network the service signal\ \fBDER\fR (Recommendation\ F.60\ [1]),
followed by a clearing signal when the maritime satellite system detects:
.sp 9p
.RT
.LP
    \(em
    that the ship's station (teleprinter, control logic,
radio equipment) is faulty;
.LP
    \(em
    failure of the answer\(hyback from the ship's teleprinter.
.PP
\fB5\fR
At the termination of the call the requirements of the clearing and
clear\(hyconfirmation signals shall apply to and from the international network
(Recommendations\ U.1, U.11,\ U.12); the maritime satellite system may use
different timings in the directions to and from the ship. It is preferred
that the total times for such signal exchanges should have a minimum time
addition to that quoted for the international network.
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ Automatic calling equipment and subscribers in the
international telex network may attempt, under certain conditions, to place
a follow\(hyon call to the same ship. Under conditions of long clear and
clear\(hyconfirmation cycle times, such calls will not be successful.
.PP
\fB6\fR
In the first generation INMARSAT system, telex characters are transmitted
in synchronous channels using 6\(hyunit frames. A telex character is thus
sent as one start element followed by the five information elements of
International Telegraph Alphabet No.\ 2. Speed differences between the
on\(hyboard teleprinter and the satellite circuit are compensated for by
occasionally
inserting six elements of Z\ polarity, i.e.,\ whenever a frame is to be sent on
.sp 9p
.RT
.LP
the synchronous channel and there is no complete telex character available.
When the characters are retransmitted into the telex network, a stop element
nominally 1.5\ units long is added. Therefore, a period of Z\ polarity
equal to the duration of a telex character may occasionally appear in the
data stream.
.PP
6.1
The design of the equipment interfacing the international
network should preferably ensure the following:
.PP
6.1.1
When type C signalling is employed to connect into the
international network, either:
.LP
    \(em
    the class\(hyof\(hytraffic and selection signals should all be
transmitted into the international network at cadence speed
without any periods of Z\ polarity between the 7\ 1/2\(hyunit characters; or
.LP
    \(em
    the class\(hyof\(hytraffic signal, the class\(hyof\(hytraffic\(hycheck
signal, the 2\ or 3\ digits of the destination code of the called network
and the first two digits of the called station should be transmitted as
a complete
block at cadence speed without any periods of Z\ polarity between the 7\
1/2\(hyunit characters. The remaining selection signals for the called
number and the EOS signal\ (\fB+\fR ) may be transmitted with periods of
Z\ polarity, providing that the signals are not delayed by more than 4\
seconds.
.bp
.PP
6.1.2
When type D signalling is employed to connect into the
international
network, the class\(hyof\(hytraffic signal(s) or network selection signals and
selection signals should be transmitted as a complete block at cadence speed
without periods of Z\ polarity between the Control Signalling Code\ (CSC)
characters.
.PP
6.1.3
If these options cannot be exercised, then the provisions of
Recommendation\ U.11, \(sc\ 13, Recommendation\ U.12, \(sc\ 3.6 or
Recommendation\ U.1, \(sc\ 6.6 shall apply.
.PP
6.2
When operation to automatic terminals, store\(hyand\(hyforward units,
etc., is required, it should be noted that periods of Z\ polarity may occur
within an answerback and text during transmission at cadence speed. (See
also Recommendation\ R.59.)
.PP
A method for avoiding periods of Z polarity within an answerback signal
is described in Appendix\ II.
.PP
\fB7\fR
Since, for automatic calls in the international telex
service,
there are no arrangements for call priorities such as are envisaged for
maritime satellite systems and since it is a principle that a telex call
should not be broken down without transmitting a service signal to the
affected
terminals, maritime satellite systems should, on exercising the maritime
priority:
.sp 9p
.RT
.LP
    a)
     attempt to set up the priority call by cutting down a call that is in
the process of being set up, i.e.\ the call\(hyconnected
signal was not yet transmitted to the international network before
cutting down an established call;
.LP
    b)
    when a call in the process of being set up is cut down,
transmit a service signal\ (\fBNC\fR ) followed by a clear
to the international network;
.LP
    c)
    where it is unavoidable that an established call be cut
down, clear the call using the standard
international clearing procedure.
.PP
\fINote\fR \ \(em\ Special signals could be used within the maritime
satellite
system to reduce the setting\(hyup times of priority calls within that system.
Such signals are not required to be related to the time scale of the cut\(hydown
of calls from or to the international network.
.PP
\fB8\fR
When the international network is used to permit an authorized telex terminal
to access a coast earth station for the purpose of making a
group call to ships
, then such a service can be provided technically:
.sp 9p
.RT
.LP
    a)
    \fIwhen the originating network cannot apply selective\fR
\fIbarring to their subscribers\fR , providing that the coast earth
station authenticates the calling terrestrial telex station by
the transmission of the WRU signal and checks the status of
the characters received from the calling terminal's answerback;
.LP
    It should be noted that the WRU should be transmitted after the
call\(hyconnected signal and the coast earth station's answerback
has been transmitted to the calling terminal;
.LP
    b)
    \fIwhen the originating telex network can apply selective\fR
\fIbarring to its subscribers\fR , providing that the telex selection
received by the coast earth station is of the format:
.sp 1P
.ce 1000
D\d1\uD\d2\uD\d3\uX\d1\uX\d2\uX\d3\u\ . |  | \ X\dk\u\ EOS
.ce 0
.sp 1P
.LP
    where D\d1\uD\d2\uD\d3\uis the appropriate telex destination code
assigned to the Maritime Satellite Service in accordance with
Recommendation\ F.69\ [2], and X\d1\uX\d2\uX\d3\u\ . |  | \ X\dk\uis the telex
number at the coast earth station defining the particular
group call
request
, which, in association with the calling terminal, may
be used to identify the appropriate listing of ships to receive
the group call. The character\ X\d1\uin combination with the
Recommendation\ F.69\ [2] code indicates to the international network that a
maritime group call is being made. The character\ X\d1\ushall be the
character\ 0 (zero). (See also Recommendation\ F.120.)
.LP
    c)
    \fIwhen type D systems exist in the connection to the\fR
\fIcalling telex terminal\fR . In that case the \*Qcalling line
identification\*U procedures of that system may be used during the setting\(hyup
phase of the connection to the
coast earth station
to
authenticate the calling terminal's identity instead of the
use of the WRU and answerback. Where the calling link
identification is not available in the terrestrial network the
Control Signalling Code (CSC) No.\ 12 will be received. Under
these circumstances the WRU/answerback sequence should be used
as detailed in \(sc\ 7,\ a).
.bp
.PP
When the request for a maritime group call, from the international network,
is rejected due to lack of authorization, the international network
should be cleared with a service signal\ (\fBNA\fR ) followed by a clearing
signal.
.PP
\fINote\fR \ \(em\ Group calls may also be set up via a store\(hyand\(hyforward
unit associated with the coast earth station. This unit should be accessed
by
subscribers or other store\(hyand\(hyforward units in accordance with the
relevant
Series\ F and\ U Recommendations. The authentication of the calling telex
subscriber should be done by the store\(hyand\(hyforward unit.
.RT
.PP
\fB9\fR
The composition of ship terminal's answerback codes
should conform to Recommendation\ F.130\ [3].
.sp 9p
.RT
.PP
\fB10\fR
Appendix I gives the characteristics and timings for INMARSAT telex circuits.
The example given is based on the implementation at the United States coast
earth stations.
\v'6p'
.sp 9p
.RT
.ce 1000
APPENDIX\ I
.ce 0
.ce 1000
(to Recommendation U.61)
.sp 9p
.RT
.ce 0
.ce 1000
\fBSignalling characteristics and timing\fR
.sp 1P
.RT
.ce 0
.ce 1000
\fBof the INMARSAT telex service\fR
.ce 0
.LP
I.1
    \fIIntroduction\fR
.sp 1P
.RT
.PP
This Appendix describes the characteristics and time sequences of the international
telex service operated over the INMARSAT maritime satellite communication
system via the USA coast earth station.
.RT
.sp 1P
.LP
I.2
    \fIShip Earth Station (SES)\fR \fIoriginated telex call\fR
.sp 9p
.RT
.PP
Figure I\(hy1/U.61 shows the signalling sequence for a telex call
originated from an SES terminal in the INMARSAT system. Figure\ I\(hy2/U.61
illustrates the telex signalling and timing sequence. The following is a
general description of the sequence of events in establishing a telex call
from an SES to a gateway switch.
.RT
.PP
I.2.1
To initiate a call, the SES sends a telex request message in
the out\(hyof\(hyband request channel. The addressed coast earth station\ (CES)
receiving the valid request message will send back an out\(hyof\(hyband
assignment
message on its normal TDM channel to the network coordination station\
(NCS). The NCS will repeat the assignment message on the common TDM channel
to which the SES is listening.
.PP
I.2.2
Upon receipt of a valid out\(hyof\(hyband assignment message from the
CES via the NCS, the SES tunes to the normal\ TDM and can then access its
assigned channel. The SES will normally achieve carrier and bit timing
synchronization within 0.58\ s after receipt of the assignment message.
This time includes assignment message decoding, carrier recovery and clock
recovery. Transmission will normally start upon frame synchronization, which
occurs in less than\ 5.25\ s.
.PP
Therefore, the normal SES response time will be less
than\ 5.8\ s as seen at the SES or 6.6\ s as seen at the coast earth
station. The time that the assignment message remains active in the coast
earth station is in addition to this 6.6\ s, allowing enough time for the
SES to
start transmitting.
.PP
I.2.3
The coast earth station, which is continually transmitting a
polarity, makes the transition A to Z\ polarity indicating call confirmation
within one character (150\ ms, not counting framing delays) after the
assignment message is formatted. In cases of heavy traffic, the assignment
message may be delayed in queue until after the transition has occurred,
i.e.\ it is possible for the A to\ Z transition to be received by the SES
before the assignment message.
.PP
I.2.4
The initial SES transmission is in the A polarity state. When
Z\ polarity is received from the coast earth station, the SES changes its
transmission from A to Z\ polarity. In the case when the A to Z\ polarity
transition on the coast earth station to SES link reaches the terminal
before the assignment message, the SES inserts no more than two characters
of
A\ polarity in the initial burst.
.bp
.PP
I.2.5
Once the coast earth station has received the SES's A to
Z\ polarity transition, call processing is started between the coast earth
station and the gateway switch. The coast earth station presents the Z\
polarity to the gateway switch and the gateway responds with a call confirmation
.LP
within 150\ ms. Within 3\ s after the call confirmation, the
gateway returns a call connected signal. The coast earth station then connects
the gateway switch to the SES. The gateway then sends its header and a
WRU to the SES. The SES will send its answerback in response to the WRU
from the
gateway switch. The SES's answerback is passed through the CES to the gateway
switch. Upon verification of the answerback by the gateway switch, it will
send a \*Q\fBGA+\fR \*U\ (Go Ahead) and the SES can then send selection
digits to the
gateway switch.
.PP
I.2.6
After this connection, the coast earth station does not respond to any
data on the line until it detects clearing.
.PP
I.2.7
The gateway switch, upon receipt of the selection sequence from
the SES, proceeds to process the call to the desired terrestrial subscriber.
As the INMARSAT system interfaces with various gateway switches, the signalling
sequences proceed according to the protocol between the particular gateway
switch and the terrestrial network.
.PP
\fINote\fR \ \(em\ The signalling sequences shown between the gateway switch
and the terrestrial network in Figure\ I\(hy1/U.61 illustrates one method
of
signalling which can be employed.
.sp 2P
.LP
I.3
    \fITerrestrial originated telex call\fR
.sp 1P
.RT
.PP
I.3.1
Figures I\(hy3/U.61 and I\(hy4/U.61 illustrate the telex signalling and
timing sequences for a telex call originated in a terrestrial network to
an SES via the INMARSAT system. As the signalling sequences between the
terrestrial networks and each gateway switch are not identical, that portion
of the signalling sequences in Figure\ I\(hy3/U.61 is for illustrative
purposes only and no attempt is made to describe all the possible sequences.
.sp 9p
.RT
.PP
I.3.2
The following paragraphs provide a description of the sequence of events
which occur between a gateway switch and an SES for a telex call
originated from the terrestrial network.
.PP
I.3.2.1
Upon receipt of the selection digits from the terrestrial network, the
gateway switch starts the signalling sequence by sending a call request
signal on an idle circuit to the coast earth station. Upon receipt, the
coast earth station returns both a call confirmation and proceed\(hyto\(hyselect
signal
within the proper intervals as shown in Figure\ I\(hy4/U.61. The gateway
switch can then proceed to send the selection digits to the coast earth
station.
.PP
I.3.2.2
The coast earth station checks the validity of the selection
digits and if correct, sends an out\(hyof\(hyband assignment message via
the NCS to the SES requested. When the assignment message has been transmitted,
the
signalling proceeds in the same manner as a call from an SES to a coast
earth station described in \(sc\ 2. Once the coast earth station has received
the
satellite call connect from the SES, it sends a call connected signal to the
gateway switch and cuts through the circuit between the SES and the gateway
switch. From this point, the coast earth station is essentially transparent
to all data on the line until it detects a clearing signal.
.PP
I.3.2.3
The gateway then sends a WRU to the SES. The SES responds to the gateway's
WRU with its answerback. The gateway switch, upon receipt of the
SES's answerback, sends its header to the SES and the SES's answerback
to the terrestrial network and the call is now in progress.
.sp 2P
.LP
I.4
    \fITelex clearing sequence\fR
.sp 1P
.RT
.PP
I.4.1
The coast earth station recognizes a clearing signal as an
A\ polarity condition of 400 to\ 1000\ ms from either the gateway switch
or an SES. After recognition of the clearing signal, the coast earth station
will disconnect the circuit and send a clear confirmation signal in both
directions.
.sp 9p
.RT
.PP
I.4.2
Release of the satellite circuit section is under the control of the coast
earth station. The SES does not stop transmission of its RF\ carrier until:
.LP
    a)
    it has returned a clear confirmation signal following the
receipt of a clearing signal from the coast earth station; or
.LP
    b)
    a clear confirmation signal is received from the coast earth
station.
.PP
In either case, the SES maintains an A polarity signal for a
maximum of 3.09\ s before transmission is terminated.
.bp
.PP
I.4.3
For 6 seconds after the successful receipt of the clearing and
clear confirmation signals over a circuit section between the coast earth
station and a gateway switch, the coast earth station will not process any
calls on that circuit section. The SES is also considered busy during this
6\(hysecond interval. This 6\(hysecond guard time is necessary to allow
for proper
clearing of the SES over the satellite circuit section. If another telex
call is received for that SES during the 6\(hysecond guard time, the coast
earth
station will send back an OCC\ service signal. Once the guard time is past
and the SES has been successfully cleared, the CES notifies the NCS that
the SES
is now idle.
.LP
.rs
.sp 47P
.ad r
\fBFIGURE I\(hy1/U.61, p. 1\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFIGURE I\(hy2/U.61, p. 2\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFIGURE I\(hy3/U.61, p. 3\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFIGURE I\(hy4/U.61, p. 4\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce 1000
APPENDIX\ II
.ce 0
.sp 1P
.ce 1000
(to Recommendation U.61)
.sp 9p
.RT
.ce 0
.sp 1P
.ce 1000
\fBMethod employed at the Nordic coast earth station\fR
.sp 1P
.RT
.ce 0
.sp 1P
.ce 1000
\fBto avoid periods of Z polarity within the answerback signal\fR
.ce 0
.sp 1P
.PP
The call set\(hyup procedures employed at the Nordic coast earth station
are similar to those shown in Appendix\ I. The coast earth station acts
as an international gateway and is directly interconnected with the
international telex exchange in Oslo.
.sp 1P
.RT
.PP
The ship's answerback is obtained by the coast earth station for both ship
originated and shore originated calls as soon as the satellite
circuit has been established. The answerback is then stored at the coast
earth station with any period of Z\ polarity omitted.
.PP
Whenever the coast earth station detects a WRU signal from the
international telex network during the conversation phase, the path from the
ship earth station is blocked as soon as the WRU\ signal has been sent to the
ship. When the first few characters of the ship's answerback have been
received at the coast earth station (in order to verify the continuity
of the circuit), the coast earth station transmits the stored answerback
into the international telex network at cadence speed.
.RT
.sp 2P
.LP
    \fBReferences\fR
.sp 1P
.RT
.LP
[1]
    CCITT Recommendation \fIOperational provisions for the international\fR
\fItelex service\fR , Rec.\ F.60.
.LP
[2]
    CCITT Recommendation \fIPlan for telex destination codes\fR , Rec.\ F.69.
.LP
[3]
    CCITT Recommendation \fIMaritime answer\(hyback codes\fR , Rec.\ F.130.
\v'1P'
.sp 2P
.LP
\fBRecommendation\ U.62\fR
.RT
.sp 2P
.ce 1000
\fBGENERAL\ REQUIREMENTS\ TO\ BE\ MET\ IN\ INTERFACING\ THE\ INTERNATIONAL\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.62''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.62    %'
.ce 0
.sp 1P
.ce 1000
\fBTELEX\ NETWORK\ WITH\ THE\ FULLY\ AUTOMATED\ MARITIME\ VHF/UHF\ RADIO\
SYSTEM\fR
.ce 0
.sp 1P
.ce 1000
\fR \fI(Malaga\(hyTorremolinos, 1984)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that it is desirable that the interface between the
international telex service and the fully automated maritime VHF/UHF radio
system be defined;
.PP
(b)
that the CCIR is charged with the task of making
recommendations relating to the radio path of the fully automated maritime
VHF/UHF radio systems;
.PP
(c)
that explanation of the detail of the interface between the international
telex network and the fully automated maritive VHF/UHF radio systems would
be of assistance to the CCIR,
.sp 1P
.LP
\fIunanimously recommends\fR
.sp 9p
.RT
.PP
that the interface between the international telex network and the
automatic maritime VHF/UHF service
should be in accordance with the
following requirements:
.sp 2P
.LP
\fB1\fR     \fBGeneral\fR
.sp 1P
.RT
.PP
1.1
In this Recommendation, the term mobile\(hyservice switching
centre (MSC) is understood to mean the interworking point between the
international or national telex network and the maritime VHF/UHF\ system. The
MSC may have access to a junction called the location register which contains
the current location of the mobile stations.
.bp
.sp 9p
.RT
.PP
1.2
Fully automated maritime VHF/UHF radio systems should be capable of interfacing
the international telex network in one or more ways:
.LP
    \(em
    in accordance with:
.LP
    i)
    Recommendation U.1, Signalling conditions to be
applied in the international telex service (type\ A and
type\ B signalling);
.LP
    ii)
    Recommendation U.11, Telex and gentex signalling on
intercontinental circuits used for
intercontinental automatic transit traffic (type\ C
signalling);
.LP
    iii)
    Recommendation U.12, Terminal and transit control
signalling system for telex and similar services on
international circuits (type\ D signalling);
.LP
    \(em
    in accordance with Recommendation F.132, Procedures for use
of store and forward facilities in the maritime mobile services
for ship\(hyoriginated calls,
.LP
    \(em
    in accordance with Series F and U Recommendations on
international store and forward units.
.PP
1.3
Type D signalling (Recommendation U.12) and, as a second
choice, type\ C signalling (Recommendation\ U.11) are the preferred signalling
systems, when they are available within the national boundaries, for the
reasons given in Annex\ A to Recommendation\ U.60.
.sp 9p
.RT
.PP
1.4
The numbering and selection procedures should be in accordance
with Recommendation\ F.121.
.sp 2P
.LP
\fB2\fR     \fBShip originated calls\fR
.sp 1P
.RT
.PP
2.1
When accessing a store\(hyand\(hyforward unit, the shipboard
subscriber should select, in accordance with Recommendation\ F.121, one
of the access codes\ 21 or\ 22 possibly followed by the character\ \*Q\fB+\fR
\*U in order to gain access to the store\(hyand\(hyforward facility.
.sp 9p
.RT
.PP
2.2
For direct access to the telex network, the procedures are given in \(sc\
3.4 of Recommendation\ F.121. The following points should be observed:
.PP
2.2.1
If the end\(hyof\(hyselection character \*Q\fB+\fR \*U is not required for
technical reasons on the radio path, it must be inserted by the MSC.
.PP
2.2.2
Access codes (possibly followed by additional digits) as defined in Recommendation\
F.121 for accessing special services or facilities, may be
converted by the MSC to an appropriate number in the telex network when the
service or facility is terminated at a point in the telex network other than
the MSC.
.PP
2.3
Any service code generated in the telex network for a particular call should
be returned to the calling ship.
.sp 2P
.LP
\fB3\fR     \fBShore originated calls\fR
.sp 1P
.RT
.sp 1P
.LP
3.1
    \fIInterfacing methods\fR
.sp 9p
.RT
.PP
The following interfacing methods are possible:
.RT
.LP
    a)
    through a store\(hyand\(hyforward unit associated with one or more
MCSs;
.LP
    b)
    direct real\(hytime access through an MSC. Here, the following
sub\(hycategories may exist:
.LP
    i)
    MSC connected to location registers;
.LP
    ii)
    MSCs not connected to location registers.
.PP
The technical solutions, including routing principles, required
for each of these interfaces, are given below.
.sp 2P
.LP
3.2
    \fIStore\(hyand\(hyforward facilities\fR
.sp 1P
.RT
.PP
3.2.1
The
store\(hyand\(hyforward unit
is accessed by normal telex  procedures.
.sp 9p
.RT
.PP
3.2.2
Procedures for forwarding messages to the store\(hyand\(hyforward unit
and for retransmission of such messages should follow the normal procedures
defined in Series\ F and U\ Recommendations.
.PP
3.2.3
Message should be retained for a period of time as defined in
Recommendation F.110, \(sc\ 4.4.
.bp
.PP
3.2.4
The store\(hyand\(hyforward unit may be connected to a location register
for routing of calls to ships which are currently operating outside their
home area.
.PP
The routing of such calls are described in Annex\ A.
.PP
3.2.5
For other applications of store\(hyand\(hyforward units, see \(sc\ 3.3.6
below.
.sp 9p
.RT
.LP
3.3
    \fIMSCs connected to location registers\fR
.sp 1P
.RT
.PP
3.3.1
The technical arrangement for
location registers
is
outlined in Annex\ A.
.sp 1P
.RT
.PP
3.3.2
A system with MSCs connected to location registers corresponds to the \fIlevel\
3\fR of operation defined in \(sc\ 3.2.4 of Recommendation\ F.121.
.sp 9p
.RT
.PP
For simplicity, the MSC in which the ship station is permanently registered
will be referred to as the home MSC. If the ship is not in its home area,
the MSC in which the ship station is currently located will be referred
to as the visited\ MSC.
.PP
3.3.3
The general selection procedures to be used for setting up
calls to ships are given in Recommendation\ F.121. They may lead to the
following possibilities:
.sp 9p
.RT
.LP
    i)
    The calling subscribers enters the following number
sequence:
.sp 1P
.ce 1000
D\d1\uD\d2\u(D\d3\u)A\d1\uA\d2\u(A\d3\u)MIDX\d4\uX\d5\uX\d6\u
.ce 0
.sp 1P
.LP
    where D\d1\uD\d2\u(D\d3\u) is the Recommendation F.69
destination code of the
country in which the home MSC of the called ship is located,
A\d1\uA\d2\u(A\d3\u) is the service access code in that country and
MIDX\d4\uX\d5\uX\d6\uis the ship station number (MID\ =\ maritime
identification digit). This can only consist of 6\ digits for
reasons given in Recommendation\ F.120. This implies that ship
stations with more than 6\ digits cannot be accessed
automatically.
.LP
    \fINote\fR \ \(em\ The MID may on a regional basis be replaced by the
digits 8Y thus permitting a seventh digit\ X\d7\uof the ship
station number (see Recommendation\ F.120 for details).
.LP
    The call is routed on the international telex network
directly to the home MSC of the called ship station.
.LP
    It may also be possible to employ two\(hystage selection
where the first stage is used for accessing the location
register in the country of destination and the second stage for
transferring the
ship station number
. This procedure
would allow ship station numbers to consist of up to 9\ digits
(see note to \(sc\ 3.4.2).
.LP
    ii)
    If the country of origin has its own location register and
the country of destination has a class\(hyof\(hytraffic assigned to
the maritime VHF/UHF\ service, it would in principle be possible
to access a ship by the following selection sequence from the
calling subscriber:
.sp 1P
.ce 1000
A\d1\uA\d2\u(A\d3\u)MIDX\d4\u\ . |  |  | \dn\u
.ce 0
.sp 1P
.LP
    where A\d1\uA\d2\u(A\d3\u) is the service access code for
maritime services in the country of origin or a
Recommendation\ F.69 destination code allocated to the maritime
VHF/UHF service, and MIDX\d4\u\ . |  | \ X\dn\uis a ship station
number consisting of up to\ 9\ digits.
.LP
    Alternatively, two\(hystage selection may be used. The first
stage is used for accessing the location register and the
second stage for transferring the number of the called ship
(see note to \(sc\ 3.4.2).
.LP
    The call is forwarded to the country of destination by the
location register in the country of origin. This is done by
sending the following address sequence of digits on the
international network:
.sp 1P
.ce 1000
D\d1\uD\d2\u(D\d3\u)MIDX\d4\u\ . |  | \ X\dn\uC
.ce 0
.sp 1P
.LP
    where D\d1\uD\d2\u(D\d3\u) is the destination code of the
country of destination and C is a class\(hyof\(hytraffic character
identifying maritime VHF/UHF service in the country of
destination. The destination code D\d1\uD\d2\u(D\d3\u) is uniquely
determined from the MID part of the ship station number.
.LP
    In order to operate such a system, class of traffic signals
need to be defined or type\ A, C and\ D signalling. Type\ B
signalling
cannot support such a class of traffic signal.
.bp
.PP
3.3.4
If the called ship is currently located at another MSC than the home MSC,
the home MSC may reroute the call to the required destination. The
address format inserted by the home MSC for the purpose of rerouting would
be one of those given in \(sc\ 3.3.3 depending on the facilities available.
.sp 9p
.RT
.PP
If the call cannot be rerouted, the service code ABS or another
more suitable service code should be returned from the home MSC.
.PP
3.3.5
When operating a system where rerouting would be required, the
following time\(hyouts should be observed:
\v'2p'
.LP
    \fITypes A and B signalling (Recommendation U.1)\fR
.LP
    The time from the end of selection, combination No.\ 26\ (\fB+\fR ), or
last selection character received and the return of the call
connected signal should not exceed 60\ seconds.
\v'2p'
.LP
    \fIType C signalling (Recommendation U.11)\fR
.LP
    The time taken from the end of selection signal, combination
No.\ 26\ (\fB+\fR ), to the call\(hyconnected signal should not exceed
60\ seconds (see\ Table\ 1/U.11, remarks relating to the call\(hyconnected
signal).
\v'2p'
.LP
    \fIType D signalling (Recommendation U.12)\fR
.LP
    The time taken from the end of selection signal, CSC code
No.\ 11, to the call connected signal should not exceed 90\ seconds (see
Recommendation\ U.12, \(sc\ 3.11).
.PP
\fINote\fR \ \(em\ It should be noted that for type A, B and C signalling,
the same timings pertain to service signals (\fBNP\fR , \fBNC\fR , \fBNA\fR
, \fBOCC\fR ,\ etc.),
and that in addition for type\ D signalling the same timing pertains to
the last backward path signalling characters and terminating\(hythrough
connection.
.PP
3.3.6
For technical or operational reasons, e.g.\ when the time\(hyout
requirements of \(sc\ 3.3.5 cannot be met, the home MSC (or home location
register) of the called ship station may offer the calling subscriber,
by an appropriate service code, a store\(hyand\(hyforward service for forwarding
the call to the ship.
.sp 9p
.RT
.sp 2P
.LP
3.4
    \fIMSCs not connected to location registers\fR
.sp 1P
.RT
.PP
3.4.1
In the case of MSCs not connected to location registers, the
calling telex subscriber must know the actual location of the called ship,
e.g.\ country, MSC, coast station.
.sp 9p
.RT
.PP
This situation would correspond to the \fIlevel\ 2\fR of operation as described
in \(sc\ 3.2.3 of Recommendation\ F.121. The required selection procedure
is given in Recommendation\ F.121.
.PP
3.4.2
Two\(hystage selection may be used where the first stage is used for accessing
the required MSC (or coast station) and the second stage for
transferring the ship station number. This procedure would allow ship station
numbers to consist of up to\ 9\ digits.
.PP
\fINote\fR \ \(em\ Two\(hystage selection may be difficult from an automatic
terminal.
.PP
3.4.3
If the called ship does not respond to the call, the MSC (or coast station)
should return the service code\ ABS or another more suitable service
code.
.sp 1P
.LP
3.5
    \fIService codes\fR
.sp 9p
.RT
.PP
For unsuccessful calls, the MSC (or coast station) should return
service codes as defined in Recommendation\ F.131.
.RT
.sp 1P
.LP
3.6
    \fIMaritime answerback code\fR
.sp 9p
.RT
.PP
The answerback of the ship station should be in accordance with
Recommendation\ F.130. The MSC (or the coast station) should ensure that the
answerback which is sent into the telex network consists of 20\ consecutive
characters sent at cadence speed.
.RT
.sp 2P
.LP
\fB4\fR     \fBMaritime group calls\fR
.sp 1P
.RT
.PP
4.1
The composition of a group call address is defined in
Recommendation\ F.120.
.bp
.sp 9p
.RT
.PP
4.2
If
group call services
are at all permitted in the
maritime VHF/UHF service, the MSCs (or coast stations) should only permit
such calls from authorized telex subscribers.
.PP
The authorization may be established in one of the following
ways:
.LP
    i)
    when type A, B or C signalling is used between the MSC
(coast station) and the telex network, the WRU answerback
sequence should apply,
.LP
    ii)
    when type D signalling is used, the calling line
identification procedure should apply. If Control Signalling
Code\ No.\ 12 is received, the WRU/answerback procedure defined
above should be used.
.PP
4.3
Calls from unauthorized subscribers should be cleared with the
service code \fBNA\fR .
\v'1P'
.ce 1000
ANNEX\ A
.ce 0
.sp 1P
.ce 1000
(to Recommendation U.67)
.sp 9p
.RT
.ce 0
.sp 1P
.ce 1000
\fBUse of\fR
\fBlocation registers in the maritime VHF/UHF
service\fR \v'6p'
.sp 1P
.RT
.ce 0
.sp 1P
.PP
A.1
For the automatic maritime VHF/UHF radiotelephone service,
CCIR Recommendation\ 586 describes the procedures to be used on the radio
path for updating of location information. A similar procedure would be
applicable for the radiotelex service. The location updating is initiated
by the ship
station when the station detects a change in the coast station identity
after the criteria given in CCIR Recommendation\ 587.
.sp 1P
.RT
.PP
A.2
Each MSC is connected to a location register which keeps an
updated list of the current location of all ship stations registered in that
MSC (the home MSC of the stations). The home MSC of a ship station should be
uniquely determined from the MID and possibly one or two additional digits
of the ship station number.
.sp 9p
.RT
.PP
The location registers are interconnected for mutual updating of the location
of ship stations.
.PP
A.3
Insofar as
routing of telex calls to ships
is
concerned, there are several possibilities:
.sp 9p
.RT
.PP
A.3.1
The telex call is always routed directly to the home MSC by the
procedures given in \(sc\ 3.3.3\ i). If the called ship is at another MSC (a
visited MSC) than the home MSC, the call is rerouted by the home MSC to the
appropriate destination.
.PP
A.3.2
The call is routed to an MSC or location register in the
calling subscriber's country by the method given in \(sc\ 3.3.3\ ii). The
further
routing of the call may then be done by either of the following
methods:
.LP
    i)
    the call is routed to the home MSC and, if required,
rerouted by that MSC as described in \(sc\ A.3.1 above;
.LP
    ii)
    the MSC in the country of origin interrogates the home
location register of the mobile station in order to obtain the
required routing information. If the called ship station is
located in some visited MSC, the MSC may then route the call
directly to the required destination.
.LP
.rs
.sp 6P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fBRecommendation\ U.63\fR
.RT
.sp 2P
.ce 1000
\fBGENERAL\ REQUIREMENTS\ TO\ BE\ MET\ IN\ INTERFACING\ THE\ INTERNATIONAL\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.63''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.63    %'
.ce 0
.sp 1P
.ce 1000
\fBTELEX\ NETWORK\ WITH\ THE\ MARITIME\ \*QDIRECT\ PRINTING\*U\ SYSTEM\fR
.ce 0
.sp 1P
.ce 1000
\fR \fI(Malaga\(hyTorremolinos, 1984)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that it is desirable that the
interface between the international telex service and the maritime \*Qdirect
printing\*U system
be
defined;
.PP
(b)
that the CCIR is charged with the task of making
Recommendations relating to the radio path;
.PP
(c)
that explanation of the details of the interface between the international
telex network and the
maritime \*Qdirect printing\*U
system
would be of assistance to the CCIR,
.sp 1P
.LP
\fIunanimously recommends\fR
.sp 9p
.RT
.PP
that the following points should be taken into consideration when interfacing
the maritime \*Qdirect printing\*U system to the telex network:
.sp 2P
.LP
\fB1\fR     \fBGeneral\fR
.sp 1P
.RT
.PP
1.1
The maritime \*Qdirect printing\*U system should be capable of
interfacing the international telex network in one or more ways:
.sp 9p
.RT
.LP
    \(em
    in accordance with Recommendations U.1, U.11 and U.12
for direct real\(hytime operation,
.LP
    \(em
    in accordance with Recommendation F.132 for ship originated
access to maritime store\(hyand\(hyforward units,
.LP
    \(em
    in accordance with procedures defined in Series F and
U\ Recommendations for store\(hyand\(hyforward access by
terrestrial subscribers.
.PP
1.2
Answerback signals from the ship should be obtained both at
the beginning and at the end of the call. When such signals are transmitted
into the telex network, the coast station should make sure that they consist
of 20\ consecutive characters and are sent at cadence speed.
.PP
The answerback should be in accordance with Recommendation\ F.130.
.PP
1.3
If the coast station detects an end of telex message signal
from the ship, the existing terrestrial connection (if any) must be cleared
down and a new connection established for the next telex message. This
should apply also when the next message is intended for the same terrestrial
subscriber.
.PP
1.4
For ship originated calls, the coast station should be capable
of returning to the ship any service codes received from the telex network.
.PP
1.5
For land originated calls, service codes should be returned to
the telex network in accordance with Recommendation\ F.131.
.sp 2P
.LP
\fB2\fR     \fBSpecial conditions related to \fR \fBship originated calls\fR
.sp 1P
.RT
.PP
2.1
The selection signals received from the ship should have
formats in accordance with Recommendation\ F.60, \(sc\ 3.2.2.
.sp 9p
.RT
.PP
2.2
When accessing a maritime store\(hyand\(hyforward unit, the call
control procedures should be in accordance with the relevant Recommendations
in the Series\ F and\ U.
.PP
2.3
For direct access into the telex network, the normal telex
procedures given in Recommendations\ U.1, U.11 and\ U.12 should be followed.
In particular, the requirements given in these Recommendations with regard
to the sending of selection signals, end of selection signals and class
of traffic
signals should be observed:
.LP
    \(em
    Recommendation U.1, \(sc 6,
.LP
    \(em
    Recommendation U.11, \(sc\(sc 7 and 9,
.LP
    \(em
    Recommendation U.12, \(sc 3.5.
.bp
.sp 2P
.LP
\fB3\fR     \fBSpecial conditions related to \fR \fBland originated calls\fR
.sp 1P
.RT
.PP
3.1
For direct access from the telex network, the time\(hyout
requirements of Recommendation\ U.1, U.11 and\ U.12 should be observed:
\v'2p'
.sp 9p
.RT
.LP
    \fITypes A and B signalling (Recommendation U.1)\fR
.LP
     The time from the end of selection, combination No.\ 26\ (\fB+\fR ),
or last selection character received and the return of the call connected
signal should not exceed 60\ seconds.
\v'2p'
.LP
    \fIType C signalling (Recommendation U.11)\fR
.LP
    The time taken from the end of selection signal, combination
No.\ 26\ (\fB+\fR ), to the call\(hyconnected signal should not exceed
60\ seconds (see Table\ 1/U.11, remarks relating to the call\(hyconnected
signal).
\v'2p'
.LP
    \fIType D signalling (Recommendation U.12)\fR
.LP
    The time taken from the end of selection signal, CSC code No.\ 11,
to the call connected signal should not exceed\ 90\ seconds (see
Recommendation\ U.12, \(sc\ 3.11).
.PP
\fINote\fR \ \(em\ It should be noted that for types A, B and C signalling,
the same timings pertain to service signals (\fBNP\fR , \fBNC\fR , \fBNA\fR
, \fBOCC\fR ,\ etc.),
and that in addition for type\ D signalling the same timing pertains to
the last backward path signalling characters and terminating\(hythrough\(hyconnection.
.PP
3.2
If the time\(hyout requirements cannot be met, the coast station
may offer the calling subscriber, by an appropriate service code, a
store\(hyand\(hyforward unit for forwarding the call to the ship.
.sp 2P
.LP
\fB4\fR     \fBMaritime group calls\fR
.sp 1P
.RT
.PP
The provisions given in Recommendation\ U.62, \(sc\ 4 apply.
.RT
.LP
.rs
.sp 28P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
\fBMONTAGE:\fR PAGE ... = BLANCHE
.sp 1P
.RT
.LP
.bp
.sp 1P
.ce 1000
\v'3P'
SECTION\ 7
.ce 0
.sp 1P
.ce 1000
\fBINTERWORKING\ BETWEEN\ NEW\ INFORMATION\ SERVICES\ AND\ TELEX\fR \v'2P'
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ U.70\fR
.RT
.sp 2P
.LP
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.70''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.70    %'
.ce 1000
\fBTELEX\ SERVICE\ SIGNALS\ FOR\fR
.ce 0
.sp 1P
.ce 1000
\fBTELEX\ TO\ TELETEX\ INTERWORKING\fR
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that a basic interworking on international connections will be at 50\ bauds
using an international telex network and that any telex
subscriber can call conversion facilities in various countries;
.PP
(b)
that Recommendation F.201 specifies:
.LP
    \(em
     that a validation of a called Teletex terminal is mandatory. The validation
is performed either by a direct validation call
or by a data base access;
.LP
    \(em
    that if a message delivery to a Teletex terminal fails in the
case of interworking with two\(hystage selection procedure, the
conversion facility should send a non\(hydelivery notification to a
telex terminal;
.PP
(c)
that Recommendation S.90 specifies Teletex requirements for interworking
with the telex service and Recommendations\ S.62 and\ S.70
specify control procedures and a network\(hyindependent basic transport service
for a Teletex;
.PP
(d)
that Recommendation X.96 specifies call progress signals in a public data
network,
.sp 1P
.LP
\fIunanimously declares the following view\fR
.sp 9p
.RT
.sp 2P
.LP
\fB1\fR     \fBScope\fR
.sp 1P
.RT
.PP
This Recommendation defines service signals which are to be sent
back to the telex terminal in the event of unsuccessful validation for
called Teletex terminal addresses, and service signals of the last delivery
attempt to the Teletex terminal which are to be sent to the telex terminal
as a part of
non\(hydelivery notification.
.RT
.LP
.sp 2
.bp
.ce
\fBH.T. [T1.70]\fR
.ce
.line
.ce
\fBMONTAGE:\ REPRENDRE ORIGINAUX DU LIVRE ROUGE.\fR
.ce
PAS DE NOUVELLE SAISIE = MAINTENU LIVRE ROUGE
.ce
.line
.ce
\fBH.T. [T1.82]\fR
.T&
lw(144p) .
.T&
cw(144p) .
Generated by
_
.T&
cw(72p) | cw(72p) .
Originating SFU    Destination SFU
_
.T&
lw(72p) | lw(72p) .
UMXU \(em TT     {
SMXU \(em DN
SMXU \(em NDN
SMXU \(em CN
 }
.T&
lw(72p) | lw(72p) .
SMXU \(em SRQ    SMXU \(em SRPT
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 1/U.70 [T1.70], p.58\fR
.sp 1P
.RT
.ad b
.RT
.LP
\fBLECTURE:\fR Tableau d\*'eplac\*'e autrement (er40 blanc) \ \
Page tr\*`es courte
.sp 1P
.RT
.LP
.bp
.sp 2P
.LP
\fB2\fR     \fBPrinciples\fR
.sp 1P
.RT
.PP
The following principles should be taken into consideration:
.RT
.PP
2.1
Call progress signals arriving from the Teletex network will be
converted without changing their original meaning as far as possible.
.PP
2.2
A faulty condition between the Teletex network and the conversion facility
will be regarded as a faulty condition within the network.
.PP
2.3
A faulty condition between the Teletex network and the Teletex
terminal will be regarded as a fault of the terminal.
.sp 2P
.LP
\fB3\fR     \fBTelex service signals\fR
.sp 1P
.RT
.PP
1n general, telex service signals specified in Recommendation F.60 should
be used. However, the telex service signals listed below will be used in
the following circumstances:
.RT
.PP
3.1
1f the format of the Teletex address part is incorrect, the
service signal\ \fBNP\fR will be returned.
.PP
3.2
1f the direct validation call is unsuccessful, the conversion
facility will transmit the service signals specified in Table\ 1/U.70 to the
telex terminal.
.PP
3.3
If the validation by data base access is unsuccessful, the
conversion facility will transmit the service signals specified in
Table\ 2/U.70.
.PP
3.4
If the message delivery to the Teletex terminal is unsuccessful, the conversion
facility will transmit the service signals of the last delivery attempt
which are specified in Table\ 1/U.70, as a part of non\(hydelivery
notification to the telex terminal.
.ce 1000
.sp 2
TABLE\ 2/U.70
\fBService signals for unsuccessful\fR
.ce 0
.LP
\fBvalidation by data base access\fR Abnormal conditions
Service signal
Unsuccessful results
\fBNP\fR
.LP
\fINote\fR \ \(em\ In addition to the case \*Qthe number does not exist\*U,
other cases,
for example, \*Qthe number is being temporarily prohibited\*U or \*Qthe number
is out of order\*U, might be considered as abnormal conditions. But at this
moment such conditions and the service signals corresponding to them are
for further study.
    .PS 10
.LP
.rs
.sp 13P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fBRecommendation\ U.74\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBEXTRACTION\ OF\ \fR \fBTELEX\ SELECTION\ INFORMATION\fR  |
\fBFROM\ A\ CALLING\ TELEX\ ANSWERBACK\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.74''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.74    %'
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that there is a need for automatic address extraction
from a telex answerback (e.g. access to a telex\(hyTeletex conversion
facility\ (CF) or an SFU);
.PP
(b)
that Recommendation F.60 defines a preferred structure for the telex answerback;
.PP
(c)
that different forms of answerbacks exist;
.PP
(d)
that Recommendation F.60 | fIbis\fR defines a structure for a telex answerback
associated with an intermediate document storage device,
.sp 1P
.LP
\fIunanimously declares\fR
.sp 9p
.RT
.PP
that answerbacks are considered \*Qtechnically processable\*U
(i.e.,\ the answerback can be interpreted unambiguously to determine the F.69
code and national call number) if they contain the minimum fields defined in
Recommendation\ F.60, separated by detectable delimiters, with allowance made
for the following additions:
.LP
    \(em
    F.60 fields may or may not be in the preferred order;
.LP
    \(em
    the Telex Network Identification Code\ (TNIC) should be
preceded and succeeded by detectable delimiters:
.LP
    i)
    preceding delimiters are national call number and space,
.LP
    ii)
    succeeding delimiters are national call number, space or
end of answerback (end of answerback means no more
printable characters);
.LP
    \(em
    one hyphen or one space with the national call number is
ignored;
.LP
    \(em
    the corresponding international access code for the \*QJ\*U TNIC
is:
.LP
    i)
    72, if the national call number consists of 5 digits,
.LP
    ii)
    720, if the national call number consists of
less or more than 5\ digits.
.PP
The international access code for all other TNICs follows
Recommendation\ F.69. For conversion between TNICs and F.69\ codes, see also
Recommendation\ F.69.
.PP
An algorithm which meets the preceding criteria is shown in
Figure\ 1/U.74.
.RT
.LP
.rs
.sp 17P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFIGURE\ 1/U.74 (Sheet 1 of 2), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 32P
.ad r
\fBFIGURE\ 1/U.74 (Sheet 2 of 2),p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
\fINote\ 1\fR \ \(em\ Check the automatic emitting speed and wait for the end
of the answerback. The answerback is considered to have ended after detection
of a\ 300\ ms period of idle.
.LP
\fINote\ 2\fR \ \(em\ \*QRetry\*U refers to another attempt to trigger the
answerback.
.LP
\fINote\ 3\fR \ \(em\ Printable figures are combination No.\ 17 (1) to
combination\ No.\ 16 (0). Spaces (combination No.\ 31), hyphens (combination
No.\ 1) and equal signs (combination no.\ 22) are allowed in this field,
but are ignored.
.LP
\fINote\ 4\fR \ \(em\ Are there one or two printable letters at the end of the
answerback, preceded by a space?
.LP
\fINote\ 5\fR \ \(em\ Are there one or two printable letters following
immediately the \*Qnational call number\*U (without space between), with space
after them?
.LP
\fINote\ 6\fR \ \(em\ In the case of a letter code single \*QJ\*U corresponding
F.69
code is:
.LP
    \(em
    \ 72, if the \*Qnational call number\*U is 5\ digits long.
.LP
    \(em
    720, if the \*Qnational call number\*U is less or more than
5\ digits.
.LP
\fINote\ 7\fR \ \(em\ Are there one or two printable letters following the
\*Qnational call number\*U, and is there no further printable character
following? One space between \*Qnational call number\*U and network identification
code is
allowed.
.LP
\fINote\ 8\fR \ \(em\ Are there one or two printable letters preceding
immediately the \*Qnational call number\*U (without space between), but with a
space in front of the letter(s).
.LP
\fINote\ 9\fR \ \(em\ If unsuccessful, perform one retry after 1.5\ seconds, if
allowed in the protocol.
.LP
\fINote\ 10\fR \ \(em\ If answerback is not received automatically.
.bp
.LP
.PS 10
.sp 2P
.LP
\fBRecommendation\ U.75\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBAUTOMATIC\ CALLED\ \fR \fBTELEX\ ANSWERBACK\ CHECK\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.75''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.75    %'
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that there is a need to check the answerback of the
called telex number [e.g.\ delivery from a telex\(hyTeletex conversion
facility\ (CF)B/F or store and forward unit\ (SFU)];
.PP
(b)
that Recommendation F.60 defines a preferred structure for the telex answerback;
.PP
(c)
that different forms of answerback exist,
.PP
(d)
that Recommendation F.60 | fIbis\fR defines a structure for a telex answerback
associated with an intermediate document storage device;
.sp 1P
.LP
\fIunanimously declares\fR
.sp 9p
.RT
.PP
that the following requirements are recommended for automatic
answerback check of a called telex terminal by an administration's equipment:
.sp 2P
.LP
\fB1\fR     \fBCase\ 1:\ reference information for the check is provided by\fR \fB
\fBthe calling subscriber\fR
.sp 1P
.RT
.PP
This information can be in total or part of the called subscriber answerback
(contiguous printable characters and space). There is no restriction on
the number of characters supplied.
.PP
In this case, the called party answerback check consists of verifying the
presence of the provided character string. Considering the information
provided in the directories and terminal identifications, allowance is to be
made for the following differences:
.RT
.LP
    \(em
    one character mismatch in the letter part;
.LP
    \(em
    one hyphen or one space is ignored in the national call number.
.sp 2P
.LP
\fB2\fR \fBCase\ 2:\ no information on the answerback of the called terminal\fR
\fBis provided by the calling subscriber\fR
.sp 1P
.RT
.PP
The reference information for the answerback check is the selection information
provided by the calling subscriber.
.PP
In this case, the called party answerback check consists of:
.RT
.LP
    \(em
    extracting the national call number and F.69 code from the
answerback;
.LP
    \(em
    comparing the obtained national call number and F.69 code
with the supplied selection information code. Allowance is made
for the following cases of mismatch:
.LP
    a)
    a positive national call number match without a valid
telex national identification code\ (TNIC) match,
.LP
    b)
    a match between the least significant part of the
supplied selection information and the national call
number obtained from the called party answerback,
considered to be positive if the difference in field
length is limited to two\ characters.
.PP
\fB3\fR An algorithm which meets the preceding criteria for cases 1 and 2
is shown in Figure\ 1/U.75
.sp 9p
.RT
.PP
In some circumstances, it may be necessary to compare the
answerback of the called subscriber with the answerback received and recognized
at the beginning of the call.
.PP
In such cases, if the received string consists of more characters than
the previously recognized answerback, then a check should be made as to
whether the recognized answerback is part of the received string.
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFIGURE\ 1/U.75, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
\fINote\ 1\fR \ \(em\ Check the automatic emitting speed and wait for the end
of the answerback. The answerback is considered to have ended after detection
of a 300\ ms period of idle.
.LP
\fINote\ 2\fR \ \(em\ \*QRetry\*U refers to another attempt to trigger the
answerback.
.LP
\fINote 3\fR \ \(em\ If unsuccessful, perform one retry if allowed in the
protocol.
.LP
\fINote 4\fR \ \(em\ The answerback provided could be a contiguous part of the
expected answerback or all of it.
.LP
In case of a return call to the calling
subscriber (e.g.\ PDN (positive delivery notification) or NDN  (negative
delivery notification) delivery) the stored calling telex answerback is
considered as a \*Qprovided\*U one.
.LP
\fINote 5\fR \ \(em\ This comparison is to verify the presence of the provided
character string in the received answerback, allowing one character mismatch
in the letter part.
.LP
\fINote 6\fR \ \(em\ A zero in the selection, but not in the answerback
in front
of the national number is to be ignored. If the received figure group is
shorter than the selected one, consider it as match, but make a note in the
call record \*Qreceived figure group is not complete\*U.
It is possible that the received figure group includes the F.69 code.
.LP
\fINote 7\fR \ \(em\ Forward message, but make a note \*Qarea code\(hycheck
was not
possible\*U into the call record.
.LP
\fINote 8\fR \ \(em\ If called A/B is not available from previous procedures.
.LP
\fINote 9\fR \ \(em\ If a digit \*Q0\*U appears at this stage between the
F.69 code
and the \*QNCN\*U it should be ignored.
.LP
.PS 10
.rs
.sp 36P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
\fBMONTAGE:\fR PAGE ... = PAGE BLANCHE
.sp 1P
.RT
.LP
.bp
.sp 1P
.ce 1000
\v'3P'
SECTION\ 8
.ce 0
.sp 1P
.ce 1000
\fBTELEX\ STORE\ AND\ FORWARD\fR \v'1P'
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ U.80\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBINTERNATIONAL\fR \
\fBTELEX\ STORE\ AND\ FORWARD\fR  |
\fBACCESS\ FROM\ TELEX\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.80''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.80    %'
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that telex store and forward units exist, and are
being introduced increasingly into national networks;
.PP
(b)
that access procedures and protocols differ
significantly between different units;
.PP
(c)
that to facilitate international access to store and forward units, a standard
access procedure would be desirable,
.sp 1P
.LP
\fIunanimously declares the view\fR
.sp 9p
.RT
.PP
that the telex access procedure described in this Recommendation should
be adopted for all future store and forward units providing incoming
international telex access.
.sp 2P
.LP
\fB1\fR     \fBScope\fR
.sp 1P
.RT
.PP
1.1
This Recommendation describes a procedure for a telex subscriber to gain
access to a store and forward unit in a foreign country by using an
international telex switched connection. The procedure uses two stage
selection.
.sp 9p
.RT
.PP
1.2
This Recommendation is one of a series which define telex store
and forward services. The other Recommendations are:
.LP
    \(em
    Recommendation\ F.72:\ International telex store and
forward\ \(em\ General principles and operational aspects.
.LP
    \(em
    Recommendation\ U.81:\ International telex store and
forward\ \(em\ Delivery to telex.
.LP
    \(em
    Recommendation\ U.82:\ International telex store and
forward\ \(em\ Interconnection of telex store and forward units.
.bp
.sp 2P
.LP
\fB2\fR     \fBOutline of service features\fR
.sp 1P
.RT
.PP
2.1
The full range of service features is described in more detail
in Recommendation\ F.72.
.sp 9p
.RT
.sp 2P
.LP
2.2
    \fIService principles\fR
.sp 1P
.RT
.PP
2.2.1
The procedure defined in this Recommendation is a two stage
selection procedure whereby a calling telex subscriber gains access to a
foreign store and forward unit\ (SFU) in the first stage of selection and
inputs the called address(es) and message in the second stage of selection,
after the return of a call connected signal.
.sp 9p
.RT
.PP
The option of a store and retrieval facility is for further
study.
.PP
2.2.2
International access to the SFU should be offered on the basis of bilateral
agreement between Administrations, and barring facilities should be provided
to prevent unauthorised use. The method of barring shall be the
responsibility of the Administration of the SFU service and is beyond the
scope of this Recommendation. It may also be necessary for Administrations
to make
provision to selectively bar access to international telex SFU facilities in
other countries.
.sp 9p
.RT
.PP
2.2.3
Message input from both manual and automatic emitting devices
should be accommodated. It is also possible that messages may be received
from another SFU, and this type of input should also be accommodated by
bilateral
agreement.
.PP
2.2.4
For calling subscribers with answerbacks that cannot be processed to obtain
the calling address, the SFU shall be able to handle direct input of the
address from the subscriber, with or without prompt.
.PP
2.2.5
A status enquiry facility should be provided internationally to
provide information on message delivery in response to a request from the
originator. This message status enquiry point will be accessed by a separate
access code to that used for message input.
.PP
When the SFU provides automatic advice of delivery and
non\(hydelivery, or a request for positive delivery can be indicated, then the
provision of status enquiry facilities is optional.
.PP
2.2.6
Address validation of the called telex subscriber(s) may be
provided, however, delivery of the message to a given address cannot be
fully guaranteed.
.sp 9p
.RT
.sp 2P
.LP
\fB3\fR     \fBOutline of facilities\fR
.sp 1P
.RT
.PP
3.1
The full range of facilities is described in more detail in
Recommendation\ F.72.
.sp 9p
.RT
.sp 2P
.LP
3.2
    \fIMessage input access\fR
.sp 1P
.RT
.PP
3.2.1
Provision should be made for both single and multi\(hyaddressed
calls.
.sp 9p
.RT
.PP
3.2.2
Messages received by the SFU for delivery to destinations not
served by that SFU should be given a Non\(hyDelivery Notification with service
code\ NA for the reason of non\(hydelivery.
.PP
3.2.3
The maximum acceptable number of addresses in a multi\(hyaddress call shall
be agreed between Administrations, but should be at least\ 20. If the
maximum number of addresses is exceeded, the SFU shall return the service
code\ TMA and clear the connection.
.PP
3.2.4
An attention information field facility should be provided by the SFU which
enables each addressee of a multi\(hyaddress message to have a relevant
attention prefix preceding the message.
.PP
3.2.5
Three classes of delivery service should be provided by the SFU:
.LP
    a)
    normal delivery. The SFU delivers the message as soon as
operationally feasible after receipt;
.LP
    b)
    delayed delivery. The delay can be either:
.LP
    i)
    set by the Administration offering the SFU service, if the
calling customer selects this option,
.LP
    ii)
    set by the calling subscriber, such that delivery of the
message is not attempted until after the expiration of the
indicated delay;
.bp
.LP
    c)
    time limited delivery set by the calling subscriber, such
that delivery of the message is attempted within a specified
time limit.
.PP
The desired class of delivery should be selectable on a
destination address basis.
.PP
3.2.6
Positive delivery notification (PDN) when provided may be
requested by the calling subscriber on a per message or on a per address
basis.
.sp 9p
.RT
.PP
3.2.7
Message reference number(s) should be returned to the calling
subscriber.
.PP
3.2.8
Address correction procedures are considered desirable and may be  provided.
.PP
3.2.9
Provision should be made to accept follow\(hyon message(s) with their associated
address(es) which may be sent as separate block(s) immediately after the
first message. Provision should also be made to acknowledge acceptance
of messages, if requested by the calling terminal, at any point during
a
transaction.
.PP
3.2.10
The SFU shall not accept the input of a message or follow\(hyon
messages (in the message input mode) unless adequate storage is available.
The minimum storage available per message text input should be agreed bilaterally
between Administrations. However, it is recommended that the minimum storage
available on a per message basis should be 24 | 00\ characters. For an interim
period 12 | 00\ characters is acceptable. Longer messages may be accepted if
storage continues to be available.
.PP
3.2.11
An Input Transaction Accepted for Delivery (ITD) service signal should
be returned to the calling subscriber to indicate that the\ SFU has
accepted the message.
.PP
3.2.12
The following facilities are not accommodated in the procedures, do not
form part of this Recommendation and are for further study:
.LP
    a)
    use of pre\(hyrecorded address lists;
.LP
    b)
    message editing facilities;
.LP
    c)
    address collation facilities;
.LP
    d)
    requests for positive delivery advices;
.LP
    e)
    transparent mode in message input phase;
.LP
    f
)
    called address format checks.
.sp 2P
.LP
3.3
    \fIStatus enquiry access\fR
.sp 1P
.RT
.PP
3.3.1
Status information on messages should only be available for return to the
originator of the message.
.sp 9p
.RT
.PP
3.3.2
Status information may be requested on:
.LP
    a)
    all addresses associated with a message reference number;
.LP
    b)
    addresses which have not yet received the message;
.LP
    c)
    a specific address.
.sp 2P
.LP
\fB4\fR     \fBAccess procedures\fR
.sp 1P
.RT
.sp 1P
.LP
4.1
    \fIGeneral\fR
.sp 9p
.RT
.PP
4.1.1
Two basic access procedures should be provided:
.sp 9p
.RT
.LP
    a)
    \fIInteractive operation\fR
.LP
    Input from manual calling terminals, where the SFU may return
prompt signals.
.LP
    b)
    \fINon\(hyinteractive operation\fR
.LP
    \(em
    Either, input from automatic emitting devices or from
subscribers' terminals, where prompt signals from the\ SFU are not required;
.LP
    \(em
    or, input from another SFU
.LP
    \fINote\fR \ \(em\ detection of this type of access will rely on the
identification of the calling SFU answerback, the format of this
answerback is for further study.
.LP
    In this case the procedure used is described in
Recommendation\ U.82.
.bp
.PP
4.1.2
Figure 1/U.80 shows the recommended access procedures.
.sp 9p
.RT
.LP
.rs
.sp 38P
.ad r
\fBFigure 1/U.80, p. \ \(em\ NE PAS DEPLACER CETTE RESERVATION\fR
.sp 1P
.RT
.ad b
.RT
.LP
\fINote\ 1\fR \ \(em\ The WRU is transmitted 800\ ms after transmission of the
SFU answerback if the forward path remains idle.
.LP
\fINote\ 2\fR \ \(em\ One additional WRU shall be transmitted by the SFU if:
.LP
    a)
    there was no response to the first WRU.
.LP
    b)
    signals were received after the first WRU which could not be
identified as an answerback.
.LP
This second WRU should be transmitted when a 300\ ms idle condition
has been detected from the calling terminal at least 2\ seconds after the
transmission of the first WRU.
.LP
\fINote\ 3\fR \ \(em\ Case\ A: Procedure when calling address can be
determined from the calling terminal answerback.
.LP
\fINote\ 4\fR \ \(em\ Case\ B: Procedure when calling address cannot be
determined
from the calling terminal answerback.
.LP
\fINote\ 5\fR \ \(em\ The prompt GA and the preceding optional message
reference
information shall be transmitted three seconds after receipt of the calling
terminal answerback. If the caller initiates input within the three seconds
timeout, the message reference information and prompt will be withheld.
.bp
.LP
\fINote\ 6\fR \ \(em\ The prompt \*QADD\*U and the precedint optional message
reference
information shall be transmitted three seconds after receipt of the calling
terminal answerback. If the caller initiates input within the three seconds
timeout, the reference information and prompt will be withheld.
.LP
\fINote\ 7\fR \ \(em\ The service request CI is transmitted when the terminal
is
operating in a non\(hyinteractive mode (e.g. an automatic terminal or a manual
terminal using a tape transmitter).
.LP
\fINote\ 8\fR \ \(em\ If the calling address is expected and is not received
within 15\ seconds of the original \*QADD\*U prompt, a further prompt shall be
transmitted. The procedure is shown in Figure\ 2/U.80.
.LP
The calling address should be input in the format F.69 destination
code followed by the national telex number followed by at least 2\ carriage
returns, line feed sequences when received in the non\(hyinteractive mode.
.LP
\fINote\ 9\fR \ \(em\ The prompt GA is inhibited if the service request
CI has been
received or if the caller has initiated input.
.LP
\fINote\ 10\fR \ \(em\ Several messages can be contained within the same
transaction and are separated by EOM sequences, as in Figure\ 3/U.80.
.LP
\fINote\ 11\fR \ \(em\ The EOM signal may optionally be followed directly by
an ACK request signal. The sequence will then be as shown in Figure\ 4/U.80.
.LP
Immediately following transmission of an IMA, the SFU shall return
reference information for previous unacknowledged messages, the signal
\(<-\(==\(da\fBGA\fR \(<-\(== and then be prepared to accept further follow\(hyon
messages.
.LP
\fINote\ 12\fR \ \(em\ Following receipt of the EOT signal the SFU shall
operate
as shown in Figure\ 5/U.80.
.LP
    a)
    If the EOT signal originated from a non\(hyinteractive telex
terminal, the SFU should wait for up to 2\ seconds for a
WRU\ signal. If WRU is received, the SFU should return its
answerback
followed immediately by the ITD\ sequence. If WRU is not received
in the 2\ second period, the SFU should return the ITD\ sequence;
.LP
    b)
    If the EOT signal originated from an interactive telex
terminal, the SFU should return the ITD\ sequence as soon as
possible;
.LP
    c)
    The ITD signal and associated reference information must be
returned within 5\ seconds of the EOT\ signal.
.LP
\fINote\ 13\fR \ \(em\ If a WRU signal is received at any time during the
procedure, the SFU shall return its own answerback.
.LP
.PS 10
.LP
.rs
.sp 30P
.ad r
\fBFIGURES 2 \(em 5/U.80, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
4.2
    \fITelex access\fR
.sp 1P
.RT
.PP
4.2.1
The calling telex subscriber should establish a call to the SFU by means
of normal telex procedures.
.sp 9p
.RT
.PP
4.2.2
Following transmission of the SFU answerback, the SFU should not send a
WRU immediately. The\ SFU should monitor the forward path and transmit
the\ WRU only when an idle condition has persisted for at least 800\ ms. If a
800\ ms idle condition has not been detected within 15\ s of the
transmission of the\ SFU answerback, the call should be cleared.
.PP
\fINote\fR \ \(em\ SFU answerback is not returned if the SFU cannot accept
the guaranteed message length (see \(sc\ 3.2.9). In this case OCC is
returned.
.PP
4.2.3
An additional WRU should be transmitted if:
.sp 9p
.RT
.LP
    a)
    there is no response to the first WRU;
.LP
    b)
    signals were received after the first WRU that could not be
identified as an answerback.
.PP
The second WRU should be sent when a 300\ ms idle condition has
been received from the calling terminal at least 10\ s after the
transmission of the first\ WRU.
.PP
\fINote\fR \ \(em\ The 300\ ms and 10\ s periods suggested here are provisional
and may need to be changed in the light of experience.
.PP
If a continuous input of signals is detected for 15 seconds after the return
of the SFU answerback, the\ SFU shall clear the call.
.RT
.sp 2P
.LP
4.3
    \fIMessage reference information\fR
.sp 1P
.RT
.PP
4.3.1
The message reference information may be returned after a 3\ second timeout
from receipt of the calling terminals answerback. If the SFU detects
input before timeout, then the message reference information will be withheld.
.sp 9p
.RT
.PP
The message reference information may comprise date and time
and/or message reference number.
.sp 2P
.LP
4.3.2
    \fIDate and time\fR
.sp 1P
.RT
.PP
4.3.2.1
The date and time of message input may be returned to the
calling telex subscriber before message input.
.sp 9p
.RT
.PP
4.3.2.2
The transmitted date and time should be:
.sp 1P
.ce 1000
\(<-\(==\(uaYY\(emMM\(emDD/HH\(emNN
.ce 0
.sp 1P
.LP
where
.LP
    YY represents two numeric characters indicating the year;
.LP
    MM represents two numeric characters indicating the month;
.LP
    DD represents two numeric characters indicating the day;
.LP
    HH represents two numeric characters indicating the hour on
a 0\(hy24 basis;
.LP
    NN represents two numeric characters indicating the minute.
.PP
\fINote\fR \ \(em\ Local time of the SFU should be used.
.sp 1P
.LP
4.3.3
    \fIMessage reference number\fR
.sp 9p
.RT
.PP
A message reference number may also be returned to the calling
telex subscriber before message input.
.PP
The reference number would comprise up to six numeric characters and should
follow immediately after the date and time information after a one space
character.
.PP
The reference number should cycle through consecutively for follow\(hyon
messages within the same transaction. Accommodation should be made to cycle
the last two or three digits for follow\(hyon messages.
.RT
.sp 2P
.LP
4.4
    \fIService request\fR
.sp 1P
.RT
.sp 1P
.LP
4.4.1
    \fIInteractive service request\fR
.sp 9p
.RT
.PP
The calling telex subscriber shall be recognized as interactive by the
omission of the non\(hyinteractive service request (see \(sc\ 4.4.2).
.bp
.RT
.sp 1P
.LP
4.4.2
    \fINon\(hyinteractive service request\fR
.sp 9p
.RT
.PP
The calling telex subscriber should indicate that the transmission is from
an automatic terminal by commencing the procedure with the
non\(hyinteractive service request (characters\ CI).
.RT
.sp 2P
.LP
4.5
    \fICalling telex address\fR
.sp 1P
.RT
.PP
4.5.1
The SFU shall use an algorithm (see Recommendation U.74) to
attempt to determine the calling telex address from the captured calling
answerback. If this cannot be achieved the\ SFU shall return a prompt signal
(\(<-\(==\(da\fBADD\fR \(<-\(==) to solicit the calling subscriber number.
.sp 9p
.RT
.PP
This prompt shall be returned after the optional message reference number,
but not before a period of three seconds from receipt of the calling
terminals answerback. If the SFU detects input within this time then the
prompt will be withheld.
.PP
4.5.2
The calling address may be preceded by a CI character sequence
which signifies the non\(hyinteractive service request (see \(sc\ 4.4.2).
The\ CI
characters sequence may or may not be associated with carriage return, line
feed or letter shift characters.
.PP
4.5.3
If the calling address is not received within 15\ seconds of the
original prompt signal (ADD), another prompt shall be returned once more
to try to solicit the calling address. If another 15\ seconds elapse the
connection
shall be cleared.
.PP
4.5.4
Address input can be cancelled (in the case of mistakes) using the same
procedure as \(sc\ 4.7.10.
.PP
4.5.5
The calling address should be input in the format: F.69 code
followed by the national telex number and must be followed by at least two
carriage return, line\(hyfeed sequences when received in the non\(hyinteractive
operation. Spaces, hyphens, pluses and preceding zeros shall be ignored.
.sp 1P
.LP
4.6
    \fICommence input signal\fR
.sp 9p
.RT
.PP
If the calling address is capable of being extracted from the
answerback (see \(sc\ 4.5.1) then the\ SFU shall return a commence input signal
comprising the characters \(<-\(==\(da\fBGA\fR \(<-\(==; after the optional
message number, but not before a period of three seconds from the receipt
of the calling terminals
answerback. If the SFU detects input within this time then the prompt will
be withheld.
.PP
If the address is not capable of being extracted from the answerback, the
SFU shall not return the GA sequence, but shall return the\ ADD prompt
(see \(sc\ 4.5.1).
.PP
In this latter case the GA prompt shall normally be returned
immediately after the receipt of the calling address. However, the\ GA prompt
should be inhibited if the service request\ CI precedes the calling
address or the caller has initiated input.
.PP
If the SFU has not been able to obtain the calling address, by the
stage at which address input is expected, then the SFU will require that the
first address line is preceded with the keyword \*QADD\*U indicating that the
calling address follows.
.PP
If \*QADD\*U is not found, then the SFU will attempt to interrupt the
calling telex subscriber in accordance with Recommendation\ S.4.
.PP
If the calling subscriber is interrupted, the service signal \*QITR\*U
followed by the clearing signal, shall be sent indicating that the SFU
has been unable to obtain the calling subscriber address and the transaction
has been
terminated.
.PP
When the calling subscriber cannot be interrupted, the SFU shall
forcefully clear the connection.
.RT
.sp 2P
.LP
4.7
    \fIAddress input\fR
.sp 1P
.RT
.PP
4.7.1
The format of each address line should be as follows:
.sp 9p
.RT
.LP
    a)
    address;
.LP
    b)
    expected answerback or part of answerback;
.LP
    c)
    attention information;
.LP
    d)
    delayed delivery;
.LP
    e)
    positive delivery notification request.
.bp
.PP
However, only field a) is mandatory to the subscriber. Each
address line should not be longer than 69\ printable or space characters.
Each address line is normally delimited by carriage return and line feed.
.PP
\fINote\ 1\fR \ \(em\ Additional shift or carriage control characters have
to be ignored.
.PP
\fINote\ 2\fR \ \(em\ Address lines containing more than 69 characters are for
further study.
.RT
.PP
4.7.2
Each field within an address line should be delimited by
different combinations for each field. These combinations will be:
.sp 9p
.RT
.LP
    Combination\ No.\ 26:\ +
    End of each address
    Combination\ No.\ 24:\ /
    Start of expected answerback or part of
answerback
    Combination\ No.\ 11:\ (
    ?04
?05
    Attention line information to be
combined within these
delimiters
    Combination\ No.\ 12:\ )
    \(rb
    Combination\ No.\ 14:\ ,
    Start of other options
.PP
\fINote\ 1\fR \ \(em\ With the exception of combination\ No.\ 26\ (+) the
other combinations need not be used if the subscriber does not want to
use those
fields.
.PP
\fINote\ 2\fR \ \(em\ The optional fields may be input in any order.
.PP
\fINote\ 3\fR \ \(em\ Handling of abnormal conditions is for further study.
.RT
.PP
4.7.3
The SFU shall return a service signal (TMA) and clear the
connection if the agreed maximum number of addresses is exceeded (see
\(sc\ 3.2.3).
.sp 9p
.RT
.PP
4.7.4
The address line(s) shall be delimited from the message by means of an
EOA signal which shall be:
.sp 1P
.ce 1000
\(<-\(==\(da\fBBT\fR
.ce 0
.sp 1P
.PP
When a positive delivery notification is requested on a per
message basis, the EOA signal will be extended to include the indicator
\*QACK\*U separated by Combination No.\ 14 (,) as follows:
.sp 1P
.ce 1000
\(<-\(==\(da\fBBT\fR , \fBACK\fR
.ce 0
.sp 1P
.PP
It is acceptable for the EOA signal to appear on the same line as the last
address.
.sp 1P
.LP
4.7.5
    \fIAddress\fR
.sp 9p
.RT
.PP
This field is the only mandatory field of the address line and may be an
international telex address (in the format of the Recommendation\ F.69
destination code and national telex number) or another non\(hytelex service,\
e.g., Teletex.
.PP
(The format is left for further study.) To permit the SFU to recognize
a Teletex address, it shall be preceded by the identifier \*QTTX\*U.
.PP
If address validation is provided, the action to be taken by the SFU, if
the address is not received with a valid format, is detailed in \(sc\ 4.12.5.
.PP
The address must be terminated by a combination\ No.\ 26\ (+) whether or
not optional fields are used.
.RT
.sp 1P
.LP
4.7.6
    \fIExpected answerback or part of answerback\fR
.sp 9p
.RT
.PP
The character sequence in this field should be used as an
additional check on the called subscriber answerback before the message is
delivered. The inclusion of this field is optional.
.RT
.sp 1P
.LP
4.7.7
    \fIAttention information\fR
.sp 9p
.RT
.PP
This field may convey the name and address of the recipient in a
confidential manner. The inclusion of this field is optional.
.RT
.sp 1P
.LP
4.7.8
    \fIDelivery indicator\fR
.sp 9p
.RT
.PP
This field indicates the type of delivery required. Omission of
this field indicates that normal delivery is required. The format of the
field should be:
.RT
.LP
    a)
    D if the calling subscriber leaves the period of delay to
the discretion of the Administration providing the SFU service;
.bp
.LP
    b)
    DXY where XY are numeric characters which specify the
minimum desired delay in hours from\ 01\(hy23;
.LP
    c)
    LXY where XY are numeric characters which specify the
maximum limit for delivering the message to the addressee.
.PP
4.7.9
When a positive delivery notification is required on a per address basis,
the indicator \*QACK\*U separated by Combination No.\ 14 (,), shall be
included as part of the address.
.sp 9p
.RT
.sp 1P
.LP
4.7.10
    \fIExamples of the format of address lines:\fR \v'3p'
.sp 9p
.RT
.LP
    a)
    41994531+/994531 FUG D, D
.LP
    b)
    41662724+(ATTENTION MR S SMITH), D12
.LP
    c)
    41246178+/246178 ADAC D (ATTENTION MR SMITH)
.LP
    d)
    4625000+
.PP
4.7.11
Address line editing facilities, if provided, should operate as   follows:
.sp 9p
.RT
.PP
Any address line entered may be cancelled by the receipt of two
consecutive == characters (upper case combination\ No.\ 22).
.sp 1P
.LP
4.8
    \fICalled address validation\fR
.sp 9p
.RT
.PP
Each address line may be validated as follows:
.RT
.LP
    a)
    that the selection number consists of only numeric
characters (non\(hynumeric characters such as space, hyphen or a valid prefix
shall be tolerated) and the selection number's length falls within the
range of the number of digits accepted by the SFU;
.LP
    b)
     that the first two or three significant digits constitute a valid F.69
telex country code accepted by the SFU;
.LP
    c)
    that the remainder of the address line conforms to the
format specified in \(sc\ 4.7.
.sp 2P
.LP
4.9
    \fIMessage input\fR
.sp 1P
.RT
.PP
4.9.1
Characters received in the message text (with the exception of
Figures\ D) should be transmitted transparently by the SFU.
.sp 9p
.RT
.PP
4.9.2
Paragraph\ 6 details the action the SFU should undertake if
abnormal conditions are encountered during message input.
.sp 1P
.LP
4.10
    \fIEnd of message (EOM) signal\fR
.sp 9p
.RT
.PP
Normally, if the calling subscriber wants to input more than one
message, an end of message signal is used. This may be one of two types as
follows:
.RT
.LP
    a)
    four combinations No.\ 14 (NNNN), which is simply used to
separate messages;
.LP
    b)
    four combinations No.\ 14, then combinations\ 1, 3 and 11
(NNNNACK) which is used to separate messages \fIand\fR to request the
SFU for an input message acknowledgement (IMA) plus reference information
of those messages not previously acknowledged (see \(sc\ 4.11.4 for format).
.PP
Once this type of EOM is received the SFU shall accept
responsibility for delivery of the message, even if the subscriber clears.
.sp 2P
.LP
4.11
    \fIEnd of transaction (EOT)\fR
.sp 1P
.RT
.PP
4.11.1
The calling telex subscriber should indicate end of transaction by transmitting
four combinations\ No.\ 26 to the SFU (++++).
.sp 9p
.RT
.PP
4.11.2
This signal is normally used at the end of the last (or single)
message input during the transaction.
.bp
.sp 2P
.LP
4.12
    \fIInput transaction accepted for delivery signal (ITD)\fR
.sp 1P
.RT
.PP
4.12.1
After receipt of the EOT signal from a non\(hyinteractive calling telex
subscriber the SFU should wait up to 2\ seconds to detect any further
signals on the forward path. If a\ WRU signal is received in this period
the\ SFU should respond with the\ SFU answerback followed by the\ ITD signal.
If no
further signals are received during this period the\ SFU should return
the\ ITD signal, plus reference information (as in \(sc\ 4.3) followed
by clear.
.sp 9p
.RT
.PP
4.12.2
After receipt of the EOT signal from an interactive telex terminal the
SFU should return the ITD signal as soon as possible.
.PP
4.12.3
ITD reference information must be returned within 5 seconds of the EOT
signal in \(sc\ 4.11.1 and \(sc\ 4.11.2 above to avoid excessive holding
times.
.PP
4.12.4
The ITD signal should be followed by the date and time, message
reference number(s) and an indication of the total number of messages. When
more than one message has been received, the reference information returned
shall be that of the first and last message, e.g.:
.sp 1P
.ce 1000
ITD\ YY\(hyMM\(hyDD/HH\(hyNN
.ce 0
.sp 1P
.ce 1000
(XXXABC\(hyXXXDEF)\ P
.ce 0
.sp 1P
.LP
where
.LP
    XXXABC is the first serial number
.LP
    XXXDEF is the last serial number
.LP
    P is the number of messages acknowledged.
.PP
4.12.5
Where address format validation is to be provided, there will be one ITD
signal per message. It shall be followed by a list of all rejected
addresses, for the corresponding message. Each rejected address may be
followed by the appropriate service signal indicating reason for failed
validation,\ e.g.:
.sp 9p
.RT
.sp 1P
.ce 1000
REJ XXXXX YY
.ce 0
.sp 1P
.LP
where
.LP
    REJ is the service signal indicating rejection of the given
address;
.LP
    XXXXX is the rejected address; and
.LP
    YY the appropriate service signal, e.g., NP, FMT, etc.
.PP
In the case where all addresses have failed validation, then the SFU should
attempt to interrupt the calling telex subscriber in accordance with Recommendation\
S.4.
.PP
If the calling subscriber can be interrupted, the service signal
\*QITR\*U, followed by the clearing signal shall be sent indicating that all
address validations have failed and the transaction has been terminated.
.PP
When the calling subscriber cannot be interrupted, the SFU shall
forcefully clear the connection.
.RT
.sp 2P
.LP
\fB5\fR     \fBStatus enquiry\fR
.sp 1P
.RT
.PP
\fINote\fR \ \(em\ This facility is for further study.
.RT
.sp 1P
.LP
5.1
    \fIStatus enquiry request\fR
.sp 9p
.RT
.PP
5.1.1
A calling telex subscriber, having selected the status enquiry
point (see \(sc\(sc\ 2.2.5 and\ 3.3) must give the SFU the following information:
.sp 9p
.RT
.LP
    a)
    the message reference information (see \(sc\ 4.3);
.LP
    b)
    an indication of whether the enquiry concerns all addresses
associated with a message, \fIor\fR whether the enquiry concerns only
address(es) which have not yet received the message, \fIor\fR a specified
address.
.PP
Status report information should be provided for all addresses
unless the message reference number is followed by combination\ No.\ 22\ (=),
which signifies that the enquiry concerns only addresses which have not yet
received the message. Also, if this character is followed by an address,
this shall signify a status request on a specific address. Several reference
number lines may be entered each separated by carriage return, line feed.
.PP
Termination of a status enquiry request will be indicated by the end of
status request signal (EOSR), combination\ No.\ 26\ (+).
.bp
.RT
.PP
5.1.2
If characters are not received on the forward path within
3\ seconds of the status enquiry mode being selected, the SFU shall return a
prompt signal which shall comprise combination\ No.2\ (?).
.sp 9p
.RT
.PP
5.1.3
If a message reference number is not received either in full, or in part,
within 20\ seconds of the prompt being returned, the SFU should clear the
connection.
.PP
5.1.4
If an EOSR signal is not received within 20\ s of the message
reference number(s) input, the SFU shall continue as if an EOSR\ signal
had been received.
.sp 2P
.LP
5.2
    \fIThe status report\fR
.sp 1P
.RT
.PP
5.2.1
The status report format will be consistent with the notification advice
format dealt with in Recommendation\ U.81.
.sp 9p
.RT
.PP
Two types of status report are returned:
.LP
    a)
    delivered;
.LP
    b)
    not delivered.
.PP
See Recommendation U.81, \(sc\ 4.3.6 for report formats.
.sp 2P
.LP
\fB6\fR     \fBAbnormal conditions during message input\fR
.sp 1P
.RT
.sp 1P
.LP
6.1
    \fITelex subscriber clearing during text input without EOT\fR
.sp 9p
.RT
.PP
The SFU shall not forward the message to the called telex
subscriber(s)
.PP
The incomplete message should either be cancelled or optionally sent to
an operator assistance position. Messages previously acknowledged in the
same transaction shall be transmitted normally.
.RT
.sp 1P
.LP
6.2
     \fITelex subscriber stopping transmission for a certain time without\fR
\fItransmitting the EOT signal, or transmitting a partial or invalid EOT\fR
\fIsignal\fR
.sp 9p
.RT
.PP
See Figure\ 6/U.80.
.PP
If at any time between the SFU returning the GA prompt (Case\ A),
or the calling address prompt (Case\ B) and the detection of the EOT signal
the SFU detects a 30\ second period of idle, the following shall apply:
the SFU
shall send a GA prompt to the telex subscriber in order to request more
information input (text, EOM or EOT). If after a further 30\ s no more
characters are received, the SFU shall:
.RT
.LP
    a)
     either send BMC service code and clear the call (if the SFU cancels incomplete
messages); or
.LP
    b)
     clear the call (if the SFU sends the message to an operator assistance
position).
.PP
If previous message(s) in the same transaction were delimited by NNNNACK,
these shall be transmitted normally.
.LP
.rs
.sp 8P
.ad r
\fBFigure 6/U.80, p.\fR
.sp 9p
.RT
.ad b
.RT
.sp 1P
.LP
6.3
    \fITelex subscriber sending WRU to the SFU during text input\fR
.sp 9p
.RT
.PP
The SFU should return its answerback after receiving a WRU. In
addition, if:
.RT
.LP
    a)
    WRU is followed by text, message input is continued after
the SFU answerback. Also, the WRU is deleted from the message text.
.LP
    b)
    WRU is followed by a clear from telex, the SFU proceeds in   \(sc\ 6.1 above.
.LP
    c)
     WRU is followed by a lack of transmission (pause), the SFU proceeds as
in \(sc\ 6.2 above.
.bp
.sp 1P
.LP
6.4
    \fITelex subscriber sending text after the EOT signal\fR
.sp 9p
.RT
.PP
See Figure 7/U.80.
.RT
.PP
6.4.1
Any characters received between EOT and ITD (with the exception of WRU)
will be ignored.
.sp 9p
.RT
.PP
6.4.2
The SFU should immediately attempt to prevent further characters being
sent by transmitting a sequence of TTT |  |  | \ characters for a maximum
of 20\ s.
.PP
6.4.3
If the calling terminal stops transmission for 150\ ms within a
20\ second period, the SFU shall return an ITD\ service signal followed by a
clear.
.PP
6.4.4
If the terminal continues to transmit characters after the
20\ second period, the SFU should forcefully clear the connection back to the
calling terminal.
.PP
6.4.5
The SFU should attempt to deliver the message text received before EOT
as for a normal message input.
.LP
.rs
.sp 14P
.ad r
\fBFigure 7/U.80, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.5
    \fITelex subscriber clearing after EOT, but before ITD\fR
.sp 9p
.RT
.PP
The message shall be forwarded normally by the SFU under these
circumstances.
.RT
.sp 1P
.LP
6.6
     \fITelex subscriber sending national variants of ITA No.\ 2 alphabet\fR
\fI(\(uaF, \(uaG, \(uaH)\fR
.sp 9p
.RT
.PP
Since Recommendation F.60, \(sc\ A.3.8 recommends that these
combinations should not be used for international communications, the SFU
should not monitor for their use and these combinations will be passed on to
the called subscribers if received.
.RT
.sp 1P
.LP
6.7
    \fITelex subscriber sending J, Bell combination (\(uaJ)\fR
.sp 9p
.RT
.PP
The SFU should also transmit this combination if received, to the called
party.
.RT
.sp 2P
.LP
6.8
    \fISFU storage capacity overflow during telex message input\fR
.sp 1P
.RT
.PP
6.8.1
If the number of characters received by the SFU during a message input
exceeds the available storage to that input (which may be greater than
the agreed minimum storage, see \(sc\ 3.2.9), the SFU should discard the excess
characters, no attempt should be made by the SFU to overwrite previously
stored characters.
.sp 9p
.RT
.PP
6.8.2
When this occurs the SFU should immediately attempt to prevent the calling
telex subscriber from sending further characters by transmitting a
sequence of TTT |  |  | \ characters for a maximum of 20\ s.
.PP
6.8.3
If the calling terminal stops transmission for 150\ ms within a
20\ second period, the SFU should return the message length exceeded indication
(LDE) and then wait for the EOT or NNNNACK in accordance with \(sc\ 6.2.
.bp
.PP
6.8.4
If the terminal continues to transmit characters after the
20\ second period, the SFU should forcefully clear the connection back to the
calling terminal.
.PP
6.8.5
If an EOT/NNNNACK is received within the 20 second period, the SFU should
attempt to deliver the message text, accepted and stored, preceded by a
special text prefix to indicate to the called telex subscriber that the
message may be incomplete. If an EOT/NNNNACK is not received the SFU shall
proceed as in \(sc\ 6.1.
.PP
6.8.6
If the SFU has insufficient storage to receive messages (see
\(sc\ 3.2.9) it should still continue to process status enquiry requests.
.sp 1P
.LP
6.9
    \fIMaximum input duration exceeded\fR
.sp 9p
.RT
.PP
If the time taken for a single transaction exceeds 2\ hours, the SFU shall
act in accordance with\ \(sc\ 6.8.
.RT
.sp 1P
.LP
6.10
    \fIRepeated characters during message input\fR
.sp 9p
.RT
.PP
The SFU shall be capable of detecting continuous reception of one character
combination and shall recognize this as a \*Qtape stuck\*U condition. The
SFU shall detect this condition only after receipt of 80\ identical combinations
received consecutively. The SFU shall attempt to signal the calling terminal
by transmitting a sequence of TTT |  |  | \ characters for a maximum of
20\ s.
If the character combinations become different the SFU shall continue with
the message input and deliver all characters received. If the \*Qtape struck\*U
condition remains at the end of 20\ s, the SFU shall clear the connection
and follow the procedure outlined in \(sc\ 6.1\ above.
\v'1P'
.RT
.sp 2P
.LP
\fBRecommendation\ U.81\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBINTERNATIONAL\ \fR \fBTELEX\ STORE\ AND\ FORWARD\ \(em\ DELIVERY\ TO\
TELEX\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.81''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.81    %'
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1989)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
that telex store and forward units exist and are being introduced increasingly
into national networks;
.PP
(b)
that delivery procedures differ significantly between  different units;
.PP
(c)
that a standard delivery procedure would be desirable for international
working,
.sp 1P
.LP
\fIunanimously declares the view\fR
.sp 9p
.RT
.PP
that the international telex delivery procedure described in this Recommendation
should be adopted for all future telex store and forward
units.
.sp 2P
.LP
\fB1\fR     \fBScope\fR
.sp 1P
.RT
.PP
1.1
This Recommendation outlines procedures for the delivery of
international telex messages by a store and forward unit\ (SFU).
.sp 9p
.RT
.PP
1.2
The Recommendation comprises the following:
.PP
1.2.1
Message forwarding procedure.
.PP
1.2.2
Delivery re\(hyattempt.
.PP
1.2.3
Notification procedure.
.bp
.PP
1.3
The procedures detailed in this Recommendation specify the
minimum requirement that should be provided by the telex\ SFU.
.sp 9p
.RT
.PP
1.4
The procedures should apply to all classes of message delivery.
.PP
1.5
The priority and time of message delivery should be the
responsibility of the telex\ SFU that has accepted the input message for
delivery.
.PP
In the case of international interworking between telex SFUs, the priority
and time of message delivery may be controlled by the originating or destination\
SFU, subject to bilateral agreement between the Administrations
concerned.
.PP
1.6
This Recommendation is one of a series which define telex store and forward
services. These Recommendations are:
.sp 9p
.RT
.LP
    \(em
    Recommendation\ F.72:\ International telex store and forward \(em
General principles and operational aspects.
.LP
    \(em
    Recommendation\ U.80:\ International telex store and forward \(em
Access from telex.
.LP
    \(em
    Recommendation\ U.81:\ International telex store and forward \(em
Delivery to telex.
.LP
    \(em
    Recommendation\ U.82:\ International telex store and forward \(em
International interconnection of telex store and forward
units.
.sp 2P
.LP
\fB2\fR     \fBDefinitions\fR
.sp 1P
.RT
.PP
2.1
The term \fBdelivery of messages\fR applies to the forwarding of
messages input into a telex SFU by an originating telex subscriber to a
destination telex subscriber over an international telex network.
.sp 9p
.RT
.PP
2.2
The term \fBnotification\fR applies to the forwarding of an advice of delivery/non\(hydelivery
of a message to the originating telex subscriber over an international
telex circuit.
.sp 2P
.LP
\fB3\fR     \fBTelex message forwarding procedures\fR
.sp 1P
.RT
.PP
3.1
The sequence of the message forwarding procedure components are
illustrated in Figures\ 1/U.81
and\ 2/U.81.
.sp 9p
.RT
.PP
3.2
The components of message forwarding procedures are as follows:
.sp 1P
.LP
3.2.1
    \fICall set\(hyup\fR
.sp 9p
.RT
.PP
Call set\(hyup is the establishment of a connection by an SFU over the
telex network up to and including the receipt of the call connect signal.
.PP
In the event of an unsuccessful call set\(hyup attempt, action shall be
taken in accordance with \(sc\ 5.
.RT
.sp 2P
.LP
3.2.2
    \fICalled subscriber answerback validation\fR
.sp 1P
.RT
.PP
3.2.2.1
To ensure security of delivery the answerback of the called
subscriber should be compared with the anticipated answerback of the called
subscriber, if supplied by the originating telex subscriber.
.sp 9p
.RT
.PP
3.2.2.2
The evaluation procedure is given in Recommendation\ U.75.
.sp 1P
.LP
3.2.3
    \fIStore and forward unit identification\fR
.sp 9p
.RT
.PP
The telex SFU identification shall comprise:
.RT
.LP
    \(em
    the service code CI,
.LP
    \(em
    an indication that the call is from a telex SFU,
.LP
    \(em
    the date and time of transmission (optional).
.sp 1P
.LP
3.2.4
    \fIMessage identification\fR
.sp 9p
.RT
.PP
The telex SFU should transmit to the called subscriber a message
identification sequence comprising:
.RT
.LP
    a)
    the message reference as allocated and advised to the
originating subscriber at the time of input of the telex message for onward
delivery;
.LP
    b)
    the date and time of message input as issued to the
originating telex subscriber in accordance with Recommendation\ U.80.
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 1/U.81, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 21P
.ad r
\fBFigure 2/U.81, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
3.2.5
    \fIAnswerback of originating telex subscriber\fR
.sp 9p
.RT
.PP
The telex SFU shall transmit to the called subscriber the
answerback of the originating subscriber as received at the time of message
input.
.RT
.sp 2P
.LP
3.2.6
    \fIMessage text\fR
.sp 1P
.RT
.PP
3.2.6.1
The telex SFU should transmit to the called subscriber any
message header information together with the stored message in the format in
which it was originated by the calling subscriber.
.sp 9p
.RT
.PP
3.2.6.2
The EOM/EOT separators and WRU shall not be transmitted.
.PP
3.2.6.3
If any signal is received on the backward path during the message text
delivery, transmission of the message text shall be stopped for 2\ seconds.
If during that time further signals or a clearing condition is received,
the
call shall be cleared and the message delivery deemed unsuccessful, and
action taken in accordance with \(sc\ 5.4. If no further signals are seen
on the backward path during that time, transmission of the message text
shall be resumed.
.sp 2P
.LP
3.2.7
    \fICalled subscriber answerback comparison\fR
.sp 1P
.RT
.PP
3.2.7.1
The answerback of the called subscriber shall be taken and
compared with that received at the start of message delivery.
.sp 9p
.RT
.PP
3.2.7.2
In the event of a mismatch of answerbacks, the answerback of the called
subscriber shall be taken once again, and if there is a match with that
received at the start of message delivery, the delivery of the message
shall be deemed successful. If there is a second mismatch, the delivery
of the message shall be considered as unsuccessful, and further delivery
attempts shall be
made in accordance with \(sc\ 5.4.
.sp 1P
.LP
3.2.8
    \fIAnswerback of originating telex subscriber\fR
.sp 9p
.RT
.PP
The answerback of the originating subscriber, as per \(sc\ 3.2.5, shall
then be sent to the called subscriber.
.RT
.sp 1P
.LP
3.2.9
    \fICall clearing sequence\fR
.sp 9p
.RT
.PP
The SFU should clear the call using normal telex clearing
procedures.
.bp
.RT
.sp 2P
.LP
\fB4\fR     \fBNotification procedures\fR
.sp 1P
.RT
.sp 1P
.LP
4.1
    \fIGeneral\fR
.sp 9p
.RT
.PP
4.1.1
The advice of non\(hydelivery shall be provided. It should preferably include
the list of addresses rejected at the time of address validation.
.sp 9p
.RT
.PP
4.1.2
The advice of delivery over an international telex circuit may be provided
subject to bilateral agreement between the Administrations concerned.
.PP
4.1.3
Information concerning delivery/non\(hydelivery of messages should be stored
and kept available for enquiries from the originator for a pre\(hydefined
period of at least 72\ hours.
.PP
4.1.4
Notification of message delivery/non\(hydelivery may be on a \*Qper
message\*U or \*Qper address\*U basis.
.PP
This Recommendation assumes that notification will be returned on a \*Qper
message\*U basis.
.PP
The provision of a periodic (e.g.\ daily) notification or journal shall
be considered an acceptable form of notification. For a typical, acceptable
journal format see Figure\ 3/U.81.
.RT
.PP
4.2
The sequence of notification forwarding procedure components
are illustrated in Figures\ 4/U.81
and 5/U.81.
.sp 9p
.RT
.LP
.sp 1P
.RT
.LP
421000Z UIT CH
.LP
CI SFU CH
.LP
TO:\ \ 421000 UIT CH
.LP
HERE IS YOUR JOURNAL FOR 28 APR 1983
.LP
.sp 1
REF
    CALLED
    ANSWERBACK
    TOD
    \ DURATION
.LP
.sp 1
.LP
12345
    080271666
    71666 HKTEL HX
    1005
    \ \ \ \ \ \ 3.1
.LP
12987
    051261848
    261848 THQPH G
    1043
    \ \ \ \ \ \ 2.1
.LP
36365
    07222500
    KDD TOKYO J22500
    1240
    \ \ \ \ \ \ 1.8
.LP
36365
    0230652464
    TRANS A LSA
    1240
    \ \ \ \ \ \ 1.9
.LP
36365
    02105827847
    CDN MARCO MTL
    2045
    \ \ \ \ \ \ 1.8
.LP
36365
    423635
    423635 HERTZ CH
    \(emABW
    CANCELLED
.LP
41696
    07514899
    14899 CWI HQ PS
    1633
    \ \ \ \ \ \ 6.0
.LP
89635
    090522222
    \(emABS
    \ \ PENDING
.LP
89777
    023232323
    232323 RCAEX UR
    1731
    \ \ \ \ \ \ 1.6
.LP
89900
    02105566412
    \(emDER
    CANCELLED
.LP
    \(em\(em\(em\(em\(em\(em\(em\(em\(em
.LP
TOTAL MINS
    \ \ \ \ \ 18.3
.LP
.sp 1
TOD 1983 04 29 0401
.LP
.sp 1
.LP
SFU CH
.LP
421000Z UIT CH
.ce 1000
FIGURE\ 3/U.81
.ce 0
.sp 1P
.ce 1000
\fBTypical journal format\fR
.ce 0
.sp 1P
.LP
.rs
.sp 2P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 4/U.81, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 21P
.ad r
\fBFigure 5/U.81, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
4.3
The components of notification forwarding procedure are as
follows:
.sp 1P
.RT
.sp 1P
.LP
4.3.1
    \fICall set\(hyup\fR
.sp 9p
.RT
.PP
The call set\(hyup should be in accordance with \(sc\ 3.2.1.
.RT
.sp 2P
.LP
4.3.2
    \fIOriginating subscriber answerback validation\fR
.sp 1P
.RT
.PP
4.3.2.1
To ensure security of delivery of the notification, the
answerback of the originating telex subscriber is taken and compared with
the answerback taken from the subscriber at the time of message input.
.sp 9p
.RT
.PP
4.3.2.2
The evaluation procedure is given in Recommendation\ U.75.
.sp 1P
.LP
4.3.3
    \fIStore and forward unit answerback\fR
.sp 9p
.RT
.PP
The answerback of the telex SFU shall be transmitted to the called  subscriber.
.RT
.sp 1P
.LP
4.3.4
    \fIStore and forward unit identification\fR
.sp 9p
.RT
.PP
The telex SFU identification shall be transmitted as per
\(sc\ 3.2.3.
.RT
.sp 1P
.LP
4.3.5
    \fIMessage identification\fR
.sp 9p
.RT
.PP
The telex SFU shall transmit to the called subscriber the message identification
sequence issued at the time of input of the message.
.PP
The format of the message identification should be in accordance with \(sc\
3.2.4.
.RT
.sp 1P
.LP
4.3.6
    \fINotification message\fR
.sp 9p
.RT
.PP
The notification advice may comprise for each applicable address of a single
or multi\(hyaddress message the following:
.PP
(See Figure\ 6/U.81 for example of suggested format.)
.bp
.RT
.LP
Example of Delivery Advice
\v'2p'
.sp 1P
.RT
.LP
5519751
    19751\ MIPEN DK
    Address \(em Expected A/B
.LP
DELIVERED
    19751\ MIPEN DK
    Advice \(em Received A/B
.LP
18:00
    \ \ \ \ \ \ 01M 20S
    Time of Delivery \(em Duration
.sp 1P
.LP
Example of Non\(hyDelivery
\v'2p'
.sp 9p
.RT
.LP
5519751
    19751\ MIPEN\ DK
    Address \(em Expected A/B
.LP
NOT DELIVERED
    Advice \(em Received A/B
.LP
    (See Note)
.LP
OCC
    \ \ \ \ \ \ \ \ \ \ \ \ \ 4
    Reason \(em No. of Attempts.
.LP
.sp 3
\fINote\fR \ \(em\ Only used if incorrect answerback is reason for
non\(hydelivery.
.ce 1000
FIGURE\ 6/U.81
\v'1P'
.ce 0
.sp 1P
.LP
4.3.6.1
    \fINon\(hydelivery advice\fR \v'3p'
.sp 9p
.RT
.LP
    \(em
    selection information (telex address)
.LP
    \(em
    expected answerback (as provided at message input)
.LP
    \(em
    notification, i.e. \*QNOT DELIVERED\*U
.LP
    \(em
    received answerback (if applicable)
.LP
    \(em
    reason for non\(hydelivery
.LP
    \(em
    number of attempts.
.sp 1P
.LP
4.3.6.2
    \fIDelivery advice\fR \v'3p'
.sp 9p
.RT
.LP
    \(em
    selection information (telex address)
.LP
    \(em
    expected answerback (as provided at message input)
.LP
    \(em
    notification, i.e. \*QDELIVERED\*U
.LP
    \(em
    received answerback
.LP
    \(em
    date and time of delivery
.LP
    \(em
    duration of call.
.sp 2P
.LP
4.3.7
    \fICalled subscriber answerback validation\fR
.sp 1P
.RT
.PP
4.3.7.1
Answerback comparison of the called subscriber shall be in
accordance with \(sc\ 3.2.7.
.sp 9p
.RT
.sp 1P
.LP
4.3.8
    \fITelex SFU answerback\fR
.sp 9p
.RT
.PP
The answerback of the SFU shall be transmitted to the called
subscriber.
.RT
.sp 1P
.LP
4.3.9
    \fICall clear\fR
.sp 9p
.RT
.PP
The calling telex SFU should clear the call using normal telex
procedures.
.bp
.RT
.sp 2P
.LP
\fB5\fR     \fBDelivery re\(hyattempt procedures\fR
.sp 1P
.RT
.PP
5.1.
The principles of Recommendation U.40 shall be applied for all
delivery/notification re\(hyattempt requirements.
.sp 9p
.RT
.PP
5.2
If the service signal RDI or NCH is received during call set\(hyup
more than once in any one message delivery/notification attempt cycle, the
message shall be considered undeliverable.
.sp 2P
.LP
5.3
    \fIRecorded message from called subscriber\fR
.sp 1P
.RT
.PP
5.3.1
If the recorded message is followed by clear, the message shall be considered
undeliverable.
.sp 9p
.RT
.PP
5.3.2
Action to be taken by the telex SFU if the recorded message is not followed
by clear, needs further study.
.PP
5.4
In the failure of an established connection per cases mentioned
in \(sc\ 3.2.6.3 or\ 3.2.7.2\ above, one further attempt to deliver the
message may be made after an interval of at least 3\ minutes; in this case
the message text shall be preceded by POSSIBLE DUPLICATE MESSAGE.
.PP
5.5
The action to be taken when a notification cannot be delivered
should be the responsibility of the Administration offering the telex\ SFU
service and is a national matter.
\v'1P'
.sp 2P
.LP
\fBRecommendation\ U.82\fR
.RT
.sp 2P
.ce 1000
\fBINTERNATIONAL\ TELEX\ STORE\ AND\ FORWARD\ \(em\fR
.EF '%    Fascicle\ VII.2\ \(em\ Rec.\ U.82''
.OF '''Fascicle\ VII.2\ \(em\ Rec.\ U.82    %'
.ce 0
.sp 1P
.ce 1000
\fBINTERCONNECTION\ OF\ TELEX\ STORE\ AND\ FORWARD\ UNITS\fR
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.sp 2P
.LP
    The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
the need for telex store and forward services;
.PP
(b)
the increasing need to transfer messages of different
types and having a variety of formats;
.PP
(c)
that the Series F Recommendations define existing
telex and new telematic services, that the Series S of Recommendations
define control procedures for new telematic services;
.PP
(d)
that Recommendations X.60, X.61, X.70, X.71, X.75 and
X.121 permit international connection between public data networks;
.PP
(e)
that the Series V Recommendations provide the means for data communication
over the telephone network;
.PP
(f
)
that the Series X Recommendations define message   handling systems,
.sp 1P
.LP
\fIunanimously declares the following\fR
.sp 9p
.RT
.sp 2P
.LP
\fB1\fR     \fBScope\fR
.sp 1P
.RT
.PP
1.1
This Recommendation defines the interworking procedures to
facilitate the international exchange of messages between computer\(hybased
telex store and forward units.
.bp
.sp 9p
.RT
.PP
1.2
This Recommendation is one of a series of Recommendations which
define international telex store and forward services. These Recommendations
are:
.LP
    \(em
     Recommendation\ F.72:\ International telex store and forward\ \(em\ general
principles and operational aspects
.LP
    \(em
    Recommendation\ U.80:\ International telex store and forward\ \(em\ access
from telex
.LP
    \(em
     Recommendation\ U.81:\ International telex store and forward\ \(em\ delivery
to telex
.LP
    \(em
    Recommendation\ U.82:\ International telex store and
forward\ \(em\ interconnection of telex store and forward units
.sp 1P
.LP
1.3
    \fIDefinitions\fR
.sp 9p
.RT
.PP
The following terms used in this Recommendation have the
undermentioned definitions:
.RT
.sp 1P
.LP
1.3.1
    \fBstore and forward unit (SFU)\fR
.sp 9p
.RT
.PP
Computer equipment with associated storage that accepts messages from telex
subscribers for subsequent delivery to specified telex address or
addresses. Conversational mode operation is not provided.
.RT
.sp 1P
.LP
1.3.2
    \fBnetwork management boundary\fR
.sp 9p
.RT
.PP
The boundary within which the telex store and forward service is provided
by one or more telex SFUs under the control of one
Administration.
.RT
.sp 1P
.LP
1.3.3
    \fBoriginating SFU\fR
.sp 9p
.RT
.PP
The telex SFU forwarding the telex message.
.RT
.sp 1P
.LP
1.3.4
    \fBdestination SFU\fR
.sp 9p
.RT
.PP
The telex SFU receiving the telex message.
.RT
.sp 1P
.LP
1.3.5
    \fBinter\(hytelex SFU messages (IM)\fR
.sp 9p
.RT
.PP
Messages transferred between telex SFUs to complete the function of message
transfer.
.RT
.sp 1P
.LP
1.3.6
    \fBmessage transfer unit (MXU)\fR
.sp 9p
.RT
.PP
The basic element of the inter\(hytelex SFU message transfer
procedure.
.RT
.sp 1P
.LP
1.3.7
    \fBuser message transfer unit (UMXU)\fR
.sp 9p
.RT
.PP
Used to carry the message submitted by a telex subscriber for
delivery to a specified address.
.RT
.sp 1P
.LP
1.3.8
    \fBservice message transfer unit (SMXU)\fR
.sp 9p
.RT
.PP
Used to convey service information about messages.
.RT
.sp 1P
.LP
1.3.9
    \fBtext transfer (TT)\fR
.sp 9p
.RT
.PP
A type of UMXU used to transfer address information and the
subscriber message.
.RT
.sp 1P
.LP
1.3.10
    \fBstatus request (SRQ)\fR
.sp 9p
.RT
.PP
A type of SMXU used to request, from a destination telex SFU, the present
status of the message.
.RT
.sp 1P
.LP
1.3.11
    \fBstatus report (SRPT)\fR
.sp 9p
.RT
.PP
A type of SMXU used to report the status of a message and sent
only in response to an SRQ.
.RT
.sp 1P
.LP
1.3.12
    \fBdelivery notification (DN)\fR
.sp 9p
.RT
.PP
A type of SMXU used to provide information on an address or
addresses to which a message has been delivered.
.bp
.RT
.sp 1P
.LP
1.3.13
    \fBnon\(hydelivery notification (NDN)\fR
.sp 9p
.RT
.PP
A type of SMXU used to provide information on an address or
addresses to which the message has not been delivered.
.RT
.sp 1P
.LP
1.3.14
    \fBcombined delivery/non\(hydelivery notification (CN)\fR
.sp 9p
.RT
.PP
A type of SMXU used to provide information on whether a message
has been delivered or not delivered to a number of addresses.
.RT
.sp 1P
.LP
1.3.15
    \fBheader\fR
.sp 9p
.RT
.PP
The portion of the MXU which contains the information to service the control
need of the calling telex SFU.
.RT
.sp 1P
.LP
1.3.16
    \fBmessage block\fR
.sp 9p
.RT
.PP
The portion of the MXU which contains the information to be
transferred between the telex SFUs.
.RT
.sp 2P
.LP
\fB2\fR     \fBService outline\fR
.sp 1P
.RT
.PP
2.1
The telex SFU service allows a telex subscriber to deposit
single or multi\(hyaddress messages with a telex\ SFU for subsequent delivery
to
the specified address or addresses. (The services and facilities to be
offered internationally are the subject of Recommendation\ F.72)
.sp 9p
.RT
.PP
2.2
In the event of a failure to deliver to any address or addresses, a non\(hydelivery
notification is issued to the originating telex subscriber. The requirement
to send a non\(hydelivery notification is mandatory. Transmission of non\(hydelivery
notifications may occur on a per address or per multi\(hyaddress
basis.
.PP
2.3
A delivery notification for successful delivery and/or subscriber initiated
status enquiry information may also be issued.
.sp 2P
.LP
\fB3\fR     \fBInternational interconnection\fR
.sp 1P
.RT
.PP
3.1
The extension of telex SFU services beyond the management
network boundary of an Administration requires co\(hyoperation between telex
SFUs across international connections.
.sp 9p
.RT
.PP
3.2
In the international interconnection of telex SFUs the
responsibility to deliver single and multi\(hyaddress messages is transferred
from the originating Administration to one or a number of destination
Administrations.
.PP
3.3
In the basic service, messages addressed to more than one
destination telex SFU management network should be separated at the originating
management network.
.PP
3.4
The possibility of forwarding messages via transit management
networks is for further study.
.PP
3.5
In the international interconnection of telex SFUs it is necessary to return
delivery/non\(hydelivery status information to the originating telex
SFU. This information is compiled on a per address basis at the destination
telex\ SFU either when the message has been delivered or when no further
attempts to deliver will be made to that address.
.PP
3.6
The return of delivery and non\(hydelivery information to the
originating telex SFU may be on a per address or per message basis.
.PP
3.7
When information is issued on a per message basis the originating telex
SFU may request interim message delivery status reports by transmitting
message status requests.
.PP
3.8
Delivery and non\(hydelivery information provided on a per message
address basis requires explicit notification to the originating telex SFU.
.PP
3.9
Delivery and non\(hydelivery information provided on a per message
basis may require only explicit notification of non\(hydeliveries and implicit
notification of deliveries.
.PP
3.10
The method employed on an international connection between telex SFUs to
transfer delivery/non\(hydelivery status information should be the subject
of bilateral agreement. Account must be taken of the means by which the
interconnection is established and the possible effects on service.
.PP
3.11
The storage of messages during the specified period for messages (or addresses)
requiring delayed delivery should generally be carried out by
the originating telex SFU. In this case the delay indicator is omitted
in the corresponding message to the destination telex\ SFU. When the delay
action is
not carried out in the originating telex\ SFU, the appropriate delay indicator
should be retained.
.bp
.sp 2P
.LP
\fB4\fR     \fBMessage transfer\fR
.sp 1P
.RT
.PP
4.1
International connection between telex SFUs may be achieved by use of the
following:
.sp 9p
.RT
.LP
    a)
    telex network;
.LP
    b)
    packet switched data networks (PSDN);
.LP
    c)
    circuit switched data networks (CSDN);
.LP
    d)
    public switched telephone network (PSTN);
.LP
    e)
    direct circuits (50 baud and medium speed).
.PP
4.2
The cooperation of two or more telex SFUs may be required to
complete the function of a message transfer. Such cooperation between telex
SFUs is achieved by use of an inter\(hytelex SFU message transfer procedure.
.PP
4.3
The general structure of an inter\(hytelex SFU message transfer
procedure is described in Figure\ 1/U.82.
.LP
.rs
.sp 31P
.ad r
\fBFigure 1/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB5\fR     \fBElements of inter\(hytelex SFU message (IM) transfer procedure\fR
.sp 1P
.RT
.PP
5.1
The basic element of the IM transfer procedure is the message transfer
unit (MXU). The MXU is classified as either a user MXU (UMXU) or
service MXU (SMXU) allowing easy identification of the function(s) for which
cooperation is required.
.sp 9p
.RT
.PP
5.2
UMXUs carry messages submitted by a telex customer for delivery to a specified
address or addresses.
.bp
.PP
5.3
SMXUs do not contain telex customer messages but are used to
convey service information about messages. SMXUs of two types have been
identified:
.LP
    a)
    notification (delivery and/or non\(hydelivery)
.LP
    b)
    status (enquiry/report)
.PP
Use of other SMXU types is for further study.
.PP
5.4
Notification SMXUs are issued automatically by the telex SFU.
Status SMXUs are generated by the telex\ SFU as a result of a customer
request or in response to a received status SMXU.
.PP
5.5
There are 6 types of MXU used to provide a telex SFU interworking  capability.
.sp 1P
.LP
5.5.1
    \fIText transfer (TT)\fR
.sp 9p
.RT
.PP
TT is used to transfer address information
and the message as a UMXU.
.RT
.sp 1P
.LP
5.5.2
    \fIStatus request (SRQ)\fR
.sp 9p
.RT
.PP
SRQ is an SMXU and is used to request
from a destination telex SFU the present status of message delivery
to:
.RT
.LP
    a)
    all addresses
.LP
    b)
    those addresses to which the message has not been delivered
.LP
    c)
    specified addresses.
.sp 1P
.LP
5.5.3
    \fIStatus report (SRPT)\fR
.sp 9p
.RT
.PP
SRPT is an SMXU and is only used in response to an SRQ.
.RT
.sp 1P
.LP
5.5.4
    \fIDelivery notification (DN)\fR
.sp 9p
.RT
.PP
DN is an SMXU and is used to provide information on an
address or addresses to which the message has been delivered.
.RT
.sp 1P
.LP
5.5.5
    \fINon\(hydelivery notification (NDN)\fR
.sp 9p
.RT
.PP
NDN is an SMXU and is used to provide information on
an address or addresses to which the message has not been delivered.
.RT
.sp 1P
.LP
5.5.6
    \fICombined delivery/non\(hydelivery notification (CN)\fR
.sp 9p
.RT
.PP
An SMXU used
to provide information on whether a message has or has not been delivered
to a number of addresses.
.RT
.PP
5.6
The originating and destination telex SFUs transmit MXUs in
accordance with Figure\ 2/U.82.
.sp 9p
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 2/U.82 [T1.82] \ \
(\*`a traiter comme tableau MEP), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB6\fR     \fBMethods of interworking\fR
.sp 1P
.RT
.PP
6.1
Administrations may provide telex SFU interworking service by
any of three methods. These methods are shown diagrammatically in
Figure\ 3/U.82.
.sp 9p
.RT
.PP
The method of interworking should be agreed bilaterally between
Administrations.
.PP
The following paragraphs describe operational procedures and are
included for explanatory purposes.
.RT
.LP
.rs
.sp 32P
.ad r
\fBFigure 3/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.1.1
    \fIMethod 1\fR \v'3p'
.sp 9p
.RT
.PP
6.1.1.1
TT is issued by the originating unit.
.PP
6.1.1.2
When the destination unit has completed call processing, CN is
returned to the originating unit.
.PP
6.1.1.3
It may only be necessary to transmit NDN instead of CN since
deliveries are implicit (see \(sc\ 3.9).
.PP
6.1.1.4
No SRQ or SRPT MXUs are issued.
.bp
.sp 1P
.LP
6.1.2
    \fIMethod 2\fR \v'3p'
.sp 9p
.RT
.PP
6.1.2.1
TT is issued by the originating unit.
.PP
6.1.2.2
NDN and DN MXUs are issued by the destination unit on a per
address basis at the time the destination unit has completed processing for
that address.
.PP
6.1.2.3
No SRQ or SRPT MXUs are issued.
.sp 1P
.LP
6.1.3
    \fIMethod 3\fR \v'3p'
.sp 9p
.RT
.PP
6.1.3.1
TT is issued by the originating unit.
.PP
6.1.3.2
SRQ MXUs are issued by the originating unit at the time of a
customer demand.
.PP
6.1.3.3
SRPT MXUs are issued by the destination unit in response to SRQ
MXUs.
.PP
6.1.3.4
When the destination unit has completed call processing CN is
returned to the originating unit.
.PP
6.1.3.5
It may only be necessary to transmit NDN instead of CN since
deliveries are implicit (see \(sc\ 3.9).
.PP
6.1.4
The preferred operation is method 3. The generation of UMXU\(hyTT,
SMXU\(hyCN, SMXU\(hySRQ and SMXU\(hySRPT is considered mandatory. The generation
of SMXU\(hyDN and SMXU\(hyNDN is optional.
.sp 2P
.LP
\fB7\fR     \fBMessage transfer unit (MXU) formation\fR
.sp 1P
.RT
.PP
7.1
An MXU is composed of a header and a message block.
.sp 9p
.RT
.sp 1P
.LP
7.1.1
    \fIHeader\fR \v'3p'
.sp 9p
.RT
.PP
7.1.1.1
The header refers to the portion of an MXU which contains
information to serve the control need of the calling telex SFU.
.PP
7.1.1.2
For an UMXU the header is constructed by the originating telex SFU at the
time a customer telex message is deposited with that unit, while in the
case of an SMXU the header is created when the service message is generated.
.PP
7.1.1.3
Changing, adding to, or deleting from header information during
the passage of an MXU through the telex\ SFU is for further study.
.sp 1P
.LP
7.1.2
    \fIMessage block\fR \v'3p'
.sp 9p
.RT
.PP
7.1.2.1
The message block contains that information that is to be
transferred between telex\ SFUs and which is the reason the MXU has been
generated.
.PP
7.1.2.2
The message block in an UMXU contains the text which is the
customer message to be transferred from the originating telex subscriber
to the specified address or addresses.
.PP
7.1.2.3
The customer message is inserted in the message block of an UMXU when a
message deposited in a telex\ SFU is to be transmitted via another telex
SFU. The message block is passed through the telex\ SFU and subsequent
telex\ SFU(s) transparently.
.PP
7.1.2.4
The message block of an SMXU contains the service information
which is inserted when the service message is generated. This information
may or may not be passed transparently through the telex SFU to the message
originating customer. The exact use of this information is a national matter
and is outside the scope of this Recommendation.
.PP
7.1.2.5
Service information required for insertion into the message block of a
notification SMXU is stored at the telex\ SFU and is continually updated
until it is automatically released to the originating telex\ SFU.
.PP
7.1.2.6
The information stored at the telex SFU may also be released in
its interim form to the originating telex\ SFU as a status report
SMXU.
.PP
7.1.2.7
The status report SMXU is an interim version of the resultant
notification SMXU.
.bp
.sp 2P
.LP
\fB8\fR     \fBMessage transfer unit (MXU) structure\fR
.sp 1P
.RT
.PP
8.1
MXUs may be of two classes: UMXU or SMXU.
.sp 9p
.RT
.PP
8.1.1
SMXUs of two types have been identified:
.LP
    a)
    notification (delivery and/or non\(hydelivery)
.LP
    b)
    status (enquiry/report)
.sp 1P
.LP
8.2
    \fIUser MXU\fR
.sp 9p
.RT
.PP
Text transfer
.RT
.LP
    Header:
    MXU type identifier
.LP
Message identity
.LP
Destination telex SFU identity
.LP
Message code indicator
.LP
    Delivery address

.sp 2P
.LP
    Expected answerback

.RT
.sp 2P
.LP
\ \ Notes 1 and 4
.sp 2P
.LP
    Attention information

.RT
.sp 2P
.IP
    Delay indication

.sp 1P
.RT
.LP
    Message\ block:
    Subscriber text
.sp 1P
.LP
8.3
    \fIService MXU\fR \v'3p'
.sp 9p
.RT
.LP
    a)
    \fIdelivery notification\fR
.LP
    Header:
    MXU type identifier
.LP
Message identity (originator)
.LP
Destination telex SFU identity
.LP
Message code indicator
.LP
Transit identities, (Note 2)
.LP
    Message\ block:
    Status

.sp 2P
.LP
    Called address

.RT
.sp 2P
.LP
    Received answerback

.RT
.sp 2P
.LP
\ \ Note 1
.sp 2P
.LP
    Date/time of last attempt

.RT
.sp 2P
.LP
    (delivery date/time)

.RT
.sp 2P
.IP
    Chargeable duration
    \v'2p'
.sp 1P
.RT
.LP
    b)
    \fInon\(hydelivery notification\fR
.LP
    Header:
    MXU type identifier
.LP
Message identity (originator)
.LP
Destination telex identity
.LP
Message code indicator
.LP
Transit identities (Note 2)
.LP
    Message\ block:
    Status

.sp 2P
.LP
    Called address

.RT
.sp 2P
.LP
    Answerback, if received
    \ \ Note 1
.sp 2P
.LP
    Date/time of last attempt

.RT
.sp 2P
.IP
    Reason
    \v'2p'
.sp 1P
.RT
.LP
    c)
    \fIcombined delivery/non\(hydelivery notification\fR
.LP
    Header:
    MXU type identifier
.LP
Message identity (originator)
.LP
Destination telex SFU identity
.LP
Message code indicator
.LP
Transit identities (Note 2)
.bp
.LP
    Message\ block:
    Status

.sp 2P
.LP
    Called address

.RT
.sp 2P
.LP
    Answerback, if received

.RT
.sp 2P
.LP
\ \ Notes 1 and 3
.sp 2P
.LP
    Date/time of last attempt

.RT
.sp 2P
.LP
    Reason

.RT
.sp 2P
.IP
    Chargeable duration
    \v'2p'
.sp 1P
.RT
.LP
    d)
    \fIstatus request\fR
.LP
    Header:
    MXU type identifier
.LP
Message identity (originator)
.LP
Destination telex SFU identity
.LP
Message code indicator
.LP
    Message\ block:
    either
    i)
    request status report on all message   addresses associated with message
.LP
    or
    ii)
    request status report on addresses to
which message has not been delivered
.LP
    or
    iii)
    request status report on specified
address(es) (Note 5)
\v'2p'
.LP
    e)
    \fIstatus report\fR
.LP
    Header:
    MXU type identifier
.LP
Message identity (originator)
.LP
Destination telex SFU identity
.LP
Message code indicator
.LP
Transit identities (Note 2)
.LP
    Message\ block:
    Status

.sp 2P
.LP
    Called address

.RT
.sp 2P
.LP
    Answerback, if received

.RT
.sp 2P
.LP
\ \ Note 1
.sp 2P
.LP
    Date/time of last attempt

.RT
.sp 2P
.LP
    Reason

.RT
.sp 2P
.IP
    Chargeable duration

.sp 1P
.RT
.PP
\fINote\ 1\fR \ \(em\ This information may be repeated on a per address
basis.
.PP
\fINote\ 2\fR \ \(em\ The use of transit identities is for further study.
.PP
\fINote\ 3\fR \ \(em\ Reason and chargeable duration are mutually exclusive.
.PP
\fINote\ 4\fR \ \(em\ In the absence of any field, the field should be
indicated by an end of field delimiter. See Annex\ A and Appendix\ I.
.PP
\fINote\ 5\fR \ \(em\ This message block contains the specified delivery
addresses.
.RT
.LP
.rs
.sp 16P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.PP
8.4
Table 1/U.82 summarizes the MXU structure.
.sp 9p
.RT
.LP
.sp 2
.ce
\fBH.T. [1T2.82]\fR
.ce
TABLE\ 1/U.82
.ce
\fBMessage transfer unit structure\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(30p) | cw(36p) | cw(30p) sw(36p) sw(30p) sw(36p) sw(30p) , ^  | c | c | c | c | c | c.
Type    UMXU    SMXU
    Text transfer  (TT)    Delivery  notification  (DN)     {
Non\(hydelivery
notification
(NDN)
 }     {
Combined delivery/
non\(hydelivery
notification (CN)
 }    Status request  (SRQ)    Status report  (SRPT)
_
.T&
lw(228p) .
.T&
lw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
    Type  identity    Type  identity    Type  identity    Type  identity    Type  identity    Type  identity
_
.T&
lw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
    Message  identity  (Note 1)    Message  identity  (Note 1)    Message  identity  (Note 1)    Message  identity  (Note 1)    Message  identity  (Note 1)    Message  identity  (Note 1)
_
.T&
lw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
     {
Destination
SFU
identity
(Note 6)
 }     {
Destination
SFU
identity
(Note 6)
 }     {
Destination
SFU
identity
(Note 6)
 }     {
Destination
SFU
identity
(Note 6)
 }     {
Destination
SFU
identity
(Note 6)
 }     {
Destination
SFU
identity
(Note 6)
 }
_
.T&
lw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
    Message  code  indicator    Message  code  indicator    Message  code  indicator    Message  code  indicator    Message  code  indicator    Message  code  indicator
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
Header    \fB.\fR    Transit  identities    Transit  identities    Transit  identities    \fB.\fR    Transit  identities
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR    Delivery  address  (Note 2)
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR     {
Expected
answerback
(Notes 2, 7)
 }
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR     {
Attention
information
(Notes 2, 7)
 }
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR     {
Delay
indication
(Notes 2, 7)
 }
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 1/U.82 [1T2.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [2T2.82]\fR
.ce
TABLE\ 1/U.82 \fI(continued)\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(30p) | cw(36p) | cw(30p) sw(36p) sw(30p) sw(36p) sw(30p) , ^  | c | c | c | c | c | c.
Type    UMXU    SMXU
    Text transfer  (TT)    Delivery  notification  (DN)     {
Non\(hydelivery
notification
(NDN)
 }     {
Combined delivery/
non\(hydelivery
notification (CN)
 }    Status request  (SRQ)    Status report  (SRPT)
_
.T&
lw(228p) .
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR    \fB.\fR    Status    Status    Status    \fB.\fR    Status
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR    \fB.\fR    Called  address    Called  address    Called  address    \fB.\fR    Called  address
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR    \fB.\fR    Received  answerback    Answerback  if received    Answerback  if received    \fB.\fR    Answerback  if received
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) , ^  | ^  | c | c | c | c | c.
Message  block  (Note 5)    Subscriber  text    Date and time  Last attempt    Date and time  Last attempt    Date and time  Last attempt    \fB.\fR    Date and time  Last attempt
        \fB.\fR    Reason  \fB.\fR    Reason  (Note 3)    \fB.\fR    Reason  (Note 3)
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR    \fB.\fR     {
Chargeable
duration
(Note 3)
 }    \fB.\fR     {
Chargeable
duration
(Note 3)
 }    \fB.\fR     {
Chargeable
duration
(Note 3)
 }
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR    \fB.\fR    \fB.\fR    \fB.\fR    \fB.\fR    Request  type
_
.T&
cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) | cw(36p) | cw(30p) .
\fB.\fR    \fB.\fR    \fB.\fR    \fB.\fR    \fB.\fR     {
Specified
address
(Notes 2, 4)
 }
.T&
lw(228p) .
.TE
.nr PS 9
.RT
.ad r
\fBTableau 1/U.82 [2T2.82], p. 26\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB9\fR     \fBMXU information fields\fR
.sp 1P
.RT
.sp 1P
.LP
9.1
    \fIType Identity\fR
.sp 9p
.RT
.PP
Types of MXU are identified by a type code of two numeric
characters. The first character identifies the type and the second the
function as described in Table\ 2/U.82. The identification of further types
of MXU is
for further study.
.RT
.ce
\fBH.T. [T3.82]\fR
.ce
TABLE\ 2/U.82
.ce
\fBMXU type identity\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(30p) | cw(54p) | cw(54p) | cw(30p) sw(30p) , ^  | ^  | ^  | c | c.
Type    MXU description    Function    Type identity
            1st  digit    2nd  digit
_
.T&
cw(30p) | cw(54p) | cw(54p) | cw(30p) | cw(30p) .
0    User message transfer    Text transfer    0    1
_
.T&
cw(30p) | cw(54p) | cw(54p) | cw(30p) | cw(30p) , ^  | ^  | c | c | c
^  | ^  | c | c | c.
1    Notification    Delivery    1    1
        Non\(hydelivery    1    2     {
Combined delivery/non\(hydelivery
 }    1    3
_
.T&
cw(30p) | cw(54p) | cw(54p) | cw(30p) | cw(30p) , ^  | ^  | c | c | c.
2    Status    Request    2    1
        Report    2    2
.TE
.LP
\fINote\fR
\ \(em\ 1st digit is the first digit to be transmitted.
.nr PS 9
.RT
.ad r
\fBTable 2/U.82 [T3.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
9.2
    \fIMessage identity\fR \v'3p'
.sp 9p
.RT
.PP
9.2.1
The message identity should consist of four fields as shown in
Table\ 3/U.82.
.ce
\fBH.T. [T4.82]\fR
.ce
TABLE\ 3/U.82
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(120p) .
Field    Content
_
.T&
lw(90p) | lw(120p) .
Originating country reference    F.69 country code
_
.T&
lw(90p) | lw(120p) .
 {
Originating telex SFU reference
 }    4\(hycharacter numeric code
_
.T&
lw(90p) | lw(120p) .
Message serial number     {
Serial number issued to the subscriber in the format specified in
Recommendation\ U.80
 }
_
.T&
lw(90p) | lw(120p) .
Date and time     {
Date and time of message submission issued to the customer in the format specified in Recommendation\ U.80
 }
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 3/U.82 [T4.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
9.3
    \fIDestination telex SFU identity\fR \v'3p'
.sp 9p
.RT
.PP
9.3.1
The destination telex SFU identity should consist of two
fields as shown in Table\ 4/U.82:
.ce
\fBH.T. [T5.82]\fR
.ce
TABLE\ 4/U.82
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(90p) | cw(120p) .
Field    Content
_
.T&
lw(90p) | lw(120p) .
Destination country reference    F.69 country code
_
.T&
lw(90p) | lw(120p) .
 {
Destination telex SFU identity
 }    4\(hycharacter numeric code
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 4/U.82 [T5.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
9.4
    \fIDelivery address(es), expected answerback(s),\fR
\fIattention\fR
\fIinformation\fR \fI, and\fR
\fIdelay indication\fR \v'3p'
.sp 9p
.RT
.PP
9.4.1
The delivery address(es), expected answerback(s), attention
information, and delay indication should be in the format specified in
Recommendation\ U.80. Expected answerback, attention information and delay
indication are optional fields.
.sp 1P
.LP
9.5
    \fIMessage code indicator\fR \v'3p'
.sp 9p
.RT
.PP
9.5.1
This field indicates the format in which the message text is
transmitted.
.PP
The message code is indicated by a single numeric character; the following
values have been assigned:
.PP
International Telegraph Alphabet No. 2 (ITA2)
0
.PP
International Alphabet No. 5 (IA5)
1
.PP
Recommendation S.61 (Teletex)
2
.PP
Additional values of message code are for further study.
.sp 1P
.LP
9.6
    \fIDelivery information\fR \v'3p'
.sp 9p
.RT
.PP
9.6.1
The delivery information should conform to the format and content specified
in Recommendation U.81.
.sp 1P
.LP
9.7
    \fINon\(hydelivery notification\fR \v'3p'
.sp 9p
.RT
.PP
9.7.1
The non\(hydelivery information should conform to the format and
content specified in Recommendation U.81.
.sp 1P
.LP
9.8
    \fICombined delivery and non\(hydelivery information\fR \v'3p'
.sp 9p
.RT
.PP
9.8.1
The combined delivery and non\(hydelivery information should conform to
the format and content specified in Recommendation U.81.
.sp 1P
.LP
9.9
    \fIStatus request information\fR \v'3p'
.sp 9p
.RT
.PP
9.9.1
The status request information should conform to the content and format
specified in Recommendation U.80.
.sp 1P
.LP
9.10
    \fIstatus report information\fR \v'3p'
.sp 9p
.RT
.PP
9.10.1
The status report information should conform to the content and
format specified in Recommendation\ U.81.
.bp
.sp 1P
.LP
9.11
    \fIStatus\fR \v'3p'
.sp 9p
.RT
.PP
9.11.1
The status field should indicate whether or not the message has
been delivered to a specified address.
.PP
The status is indicated by a single numeric character; the
following values have been assigned:
.PP
Delivered
0
.PP
Non\(hydelivery
1
.PP
Additional values of status are for further study.
.sp 1P
.LP
9.12
    \fIRequest type\fR \v'3p'
.sp 9p
.RT
.PP
9.12.1
The request type indicates whether a status request is required
for all addresses, those to which the message has not been delivered or for
those specified addresses included in the SRQ message block. See \(sc\ 8.3\ d).
.PP
The following values have been assigned:
.LP
    Request on all addresses
0
    Request non\(hydelivery reports only
1
    Request report on specified address(es)
2
.sp 1P
.LP
9.13
    \fITransit identities\fR \v'3p'
.sp 9p
.RT
.PP
9.13.1
The transit identity field is reserved for future use and may be required
for administrative purposes.
.PP
The content and format of the field is for further study.
.sp 2P
.LP
\fB10\fR \fBPrinciples of procedures and coding of inter\(hytelex SFU messages\fR
.sp 1P
.RT
.sp 1P
.LP
10.1
    \fIUse of the telex network\fR \v'3p'
.sp 9p
.RT
.PP
10.1.1
The principles for message transfers are illustrated graphically in Figures
4/U.82 to 8/U.82.
.PP
10.1.2
Call set\(hyup should use normal telex call procedures.
.PP
10.1.3
Operation will normally be half duplex. Exceptionally, responses to MXU
headers may be transmitted whilst operating in full duplex mode. The
capability to operate full duplex is subject to bilateral agreement.
.PP
10.1.4
Inter\(hytelex SFU messages should be distinguished from telex
subscriber access messages by an interworking service request identifier
(IRQ) which will be acknowledged by a service acknowledgement signal
(IACK).
.PP
10.1.5
For link control purposes a preamble should precede the message
header. This should consist of a character sequence as a block identity, a
3\ alpha character circuit identity and a 3\ numeric character serial
reference.
.PP
10.1.6
The numeric character serial reference should increment
sequentially and cyclically for each block transferred. No action is required
by an SFU when the numbers received are not sequential, but this may be
used
nationally by Administrations to indicate possible fault conditions.
.PP
10.1.7
An end of message signal should be sent by the originating telex SFU which
should be acknowledged by a message block acknowledgement signal from the
destination telex SFU. The acknowledgement signal should be a character
sequence similar to the preamble detailed in \(sc\ 10.1.5 indicating the
circuit
on which the message was originally transmitted and the serial reference.
.PP
10.1.8
If the originating telex SFU does not receive both acknowledgement signals
the original whole message (header and text) should be retransmitted.
.PP
10.1.9
Follow\(hyon messages should be indicated by the receipt of a new
message header. See Figure\ 6/U.82.
.LP
10.1.10\ It should be possible for either telex SFU to interrupt an
incoming transmission by using an interrupt transmission signal.
.LP
10.1.11\ After the reception of the last block acknowledgement, an end of
transmission signal should be transmitted by the originating unit before
normal telex clearing procedures.
.bp
.LP
10.1.12\ When the receiving telex SFU cannot offer the interworking service
or when the telex SFU cannot accept message text transfers, because of
storage limitations or failure conditions, the service signal\ \fBNC\fR
followed by a clear signal should be transmitted.
.LP
10.1.13\ When service signals are to be transmitted by the destination
telex SFU to an originating SFU that is itself transmitting, the destination
SFU shall transmit an interrupt transmission signal (see Table\ 5/U.82) until
received transmission ceases. This shall be subject to an overall timeout of
20\ seconds. The service signal shall then be transmitted following transmission
of a mark signal for 3\ seconds.
.LP
10.1.14\ All information should be coded in accordance with ITA2.
.LP
10.1.15\ The action to be taken in the event of abnormal conditions during
the message transfer stage should be the subject of bilateral agreement.
Standardization of this action is for further study.
.LP
10.1.16\ Table 5/U.82 shows the coding for interworking signals.
.LP
10.1.17\ The field delimiter for all fields in an MXU should be combination
No.\ 26 (+). This should be preceded by combination No.\ 30\ (F/S) when
necessary. The delimiters within the fields specified in \(sc\ 9.4 should
be in
accordance with Recommendation\ U.80.
.LP
10.1.18\ Examples of field coding and content of MXUs when using the telex
network are shown in Appendix\ I.
.LP
.rs
.sp 35P
.ad r
\fBFigure 4/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 33P
.ad r
\fBFigure 5/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 44P
.ad r
\fBFigure 6/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 7/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 8/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T6.82]\fR
.ce
TABLE\ 5/U.82
.ce
\fBInterworking signals\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(84p) | cw(144p) .
Description    Coding ITA2
_
.T&
lw(84p) | lw(144p) .
IRQ     {
Combination No. 29; combination No. 26; combination No.\ 3;
combination No.\ 19; combination No.\ 6 (ZCSF)
 }
_
.T&
lw(84p) | lw(144p) .
IACK     {
Combination No. 29 followed by combination No. 9, combination No. 7,
combination No. 1 (IGA)
 }
_
.T&
lw(84p) | lw(144p) .
Block identity     {
Combination No. 26; combination No. 3; combination No.\ 13;
combination No.\ 19 (ZCMS)
 }
_
.T&
lw(84p) | lw(144p) .
Circuit identity    3 alpha characters
_
.T&
lw(84p) | lw(144p) .
Serial reference    3 numeric characters
_
.T&
lw(84p) | lw(144p) .
End of message block    4 combinations No. 14 (NNNN)
_
.T&
lw(84p) | lw(144p) .
Block acknowledgement     {
Combination No. 26; combination No. 3; combination No. 1;
combination No.\ 11 (ZCAK). See \(sc 10.1.6
 }
_
.T&
lw(84p) | lw(144p) .
End of transmission    4 combinations No. 26 (ZZZZ)
_
.T&
lw(84p) | lw(144p) .
Interrupt transmission     {
Continuous combinations No. 20 until received transmission
ceases (TTTTTT...)
 }
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 5/U.82 [T6.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
10.2
    \fIUse of \fR \fIdirect circuits for asynchronous\fR \fItransmission\fR \v'3p'
.sp 9p
.RT
.PP
10.2.1
The direct circuit should be used in a half duplex mode to allow for acknowledgements
of the information transmitted. The data transmission rate to be used on
the international circuit should be agreed bilaterally.
.PP
10.2.2
The procedures and coding when using direct circuits for
interconnection between telex SFUs should be identical to those in the
case of use of the telex network but without the call set\(hyup and call
clearing phases. Thus, the procedures commence with the transmission of
the IRQ signal.
.PP
10.2.3
The characters may be coded in either ITA2 or IA5. The coding
should be fixed on a direct circuit basis and the code used should be agreed
bilaterally.
.PP
10.2.4
Where circuits are used in a bothway mode the telex call collision procedures
should be agreed bilaterally.
.PP
10.2.5
Call collision should be detected by checking the response to the service
request signal (IRQ). In cases where the response is a service request
signal from the other unit a call collision situation is indicated.
.PP
10.2.6
On circuits used for bothway transmission bilateral agreement
will be required to determine usage in each direction to minimize the
occurrence of call collisions.
.PP
10.2.7
Examples of field coding and content of MXUs when using
asynchronous circuits are shown in Appendix\ I.
.sp 2P
.LP
10.3
    \fIUse of\fR
\fIpublic switched data networks\fR
.sp 1P
.RT
.sp 1P
.LP
10.3.1
    \fIAsynchronous circuit switched data networks\fR \v'3p'
.sp 9p
.RT
.LP
10.3.1.1\ These procedures apply to data networks operating for
Recommendation X.1 user classes of service 1 and\ 2. The data transmission
rate to be used should be agreed bilaterally.
.LP
10.3.1.2\ Call connections between telex SFUs should be established in
accordance with Recommendation\ X.70.
.bp
.LP
10.3.1.3\ Telex SFU addresses used to establish the connection should
conform to Recommendation\ X.121.
.LP
10.3.1.4\ Calling and called line identifications may be requested to
verify correct connection.
.LP
10.3.1.5\ Following establishment of a connection between telex SFUs, MXUs
should be transferred in accordance with the procedures described in \(sc\
10.1 for the telex network.
.LP
10.3.1.6\ Coding should be in IA5 or ITA2 or the character set defined in
Recommendation S.61 with the message code indicator set accordingly. The
coding used on a connection between any 2\ telex SFUs should be agreed
bilaterally and should not be negotiable on a per call basis.
.LP
10.3.1.7\ Access to the interworking service may be restricted by means of
closed user group characters.
.LP
10.3.1.8\ Character conversion between ITA2 and IA5 should be carried out
by each telex SFU in accordance with Recommendation\ S.18 and between\ ITA2
and Recommendation\ S.61 in accordance with Recommendation\ S.60.
.LP
10.3.1.9\ Administrations may, following call set\(hyup, operate in accordance
with \(sc\ 10.3.2. This method of operating is a matter for further
study.
.sp 1P
.LP
10.3.2
    \fISynchronous data networks\fR \v'3p'
.sp 9p
.RT
.LP
10.3.2.1\ The procedures described in this section apply to calls
established between telex SFUs over data networks operating for
Recommendation\ X.1 user classes\ 3 to\ 11. The data transmission rate
to be used on the international circuit should be agreed bilaterally.
.LP
10.3.2.2\ The procedures may also apply to user classes 1 and 2 after call
set\(hyup (see \(sc\ 10.3.1).
.LP
10.3.2.3\ The call set\(hyup and transport procedures should be generally in
accordance with Recommendation S.70 with the following qualifications:
.LP
    i)
    the network layer should be Recommendation\ X.75 for PSDNs
and Recommendation\ X.71 for CSDNs;
.LP
    ii)
    a special class of traffic signal may be used on CSDNs;
.LP
    iii)
    a special traffic class indication may be used on PSDNs.
.LP
10.3.2.4\ Control procedures for the transfer of messages between telex
SFUs should be based on Recommendation\ S.62, CCITT \fIYellow Book\fR ,\ 1980.
.LP
10.3.2.5\ The preferred operation for the basic telex SFU interconnection
should be the TWA session mode. The TWA\ mode is preferable when status
reports are requested from the distant telex SFU. The use of the OWC session
mode may also be used and should be the subject of bilateral agreement.
.LP
10.3.2.6\ Telex SFUs may also operate in a TWS session mode in order to
increase the speed of interchange when messages are required in both
directions. The principle of operating in the TWS session mode should be
agreed bilaterally.
.LP
10.3.2.7\ The MXU should be transferred in session and document elements of
procedure.
.LP
10.3.2.8\ The UMXU should be transferred as a control document containing
the header, including delivery address(es), expected answerback, attention
information and delay indication, in the control text together with an
associated normal document containing the message block.
.LP
10.3.2.9\ The UMXU document structure is shown in Figure 9/U.82.
.LP
10.3.2.10\ The absence of the document identifier shall indicate the normal
document.
.LP
10.3.2.11\ The UMXU control document shall be transmitted first followed
immediately by the normal document.
.LP
10.3.2.12\ The SMXU should be transferred as a control document.
.LP
10.3.2.13\ The SMXU structure is shown in Figure 10/U.82.
.LP
10.3.2.14\ Any number of control and normal documents may be transferred
during a session. Figure\ 11/U.82 shows an example of a document transfer
session.
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 9/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 10/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 41P
.ad r
\fBFigure 11/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
10.3.2.15\ Page boundaries may be transmitted by the originating SFU
in a text transfer MXU in the message block. These check points will be
recognized by the destination SFU for error recovery purposes and may also
be included in the message output to the telex subscriber by the insertion
of 10\ line feeds (ITA2 combination No.\ 28).
.LP
10.3.2.16\ When the message block text has no page boundary, error
recovery procedures may be based on Annex\ G of Recommendation\ S.62.
.LP
10.3.2.17\ Any one MXU should normally be transferred during a single
session. If a session is interrupted it may be possible to continue the
transfer using CDC after setting up a new session.
.bp
.LP
10.3.2.18\ The basic telex SFU interworking connection should only
use those PGIs and PIs defined as mandatory in Tables\ 9/S.62 and\ 10/S.62.
.LP
10.3.2.19\ The use of other PGIs and PIs defined in Recommendation S.62
is for further study.
.LP
10.3.2.20\ Delivery address, expected answerback and attention information
should be transferred in a control document immediately following establishment
of document level procedures.
.LP
10.3.2.21\ MXU message blocks should be transferred in normal and control
documents as a sequence of characters coded as defined by the message code
indicator. Examples of the control text in the control document are shown in
Annex\ A.
.LP
10.3.2.22\ The control document content may serve two purposes:
.LP
    a)
    to provide management information that may be used for
accounting, statistics,\ etc.
.LP
    b)
    to provide subscriber information.
.PP
To achieve b) the information should be in a format suitable for forwarding
directly to the customer.
.LP
10.3.2.23\ The use of the control document to provide subscriber information
is a national matter.
.LP
10.3.2.24\ The parameter values should be coded in accordance with the rules
defined in Recommendation\ S.62. Thus, sequences of graphic characters
will be coded using the character repertoire defined in Recommendation\
S.61.
.LP
10.3.2.25\ The assignment of coding to the various parameter values relevant
to the mandatory PGIs and PIs defined in Recommendation\ S.62 is shown
below:
.sp 1P
.LP
10.3.2.25.1\ \fITerminal identifier of the called terminal\fR
.sp 9p
.RT
.PP
A sequence of graphic characters as defined in
Recommendation\ U.81.
.RT
.sp 1P
.LP
10.3.2.25.2\ \fITerminal identifier of the calling terminal\fR
.sp 9p
.RT
.PP
A sequence of graphic characters as defined in
Recommendation\ U.81.
.RT
.sp 1P
.LP
10.3.2.25.3\ \fIDate and time\fR
.sp 9p
.RT
.PP
A sequence of graphic characters in the format defined in
Recommendation U.81. The values should indicate the time of transmission of
the relevant command except for command document continue (CDC) where the
date and time will be those in the command document start (CDS) of the
first attempt to transmit the document.
.RT
.sp 1P
.LP
10.3.2.25.4\ \fIService identifier\fR
.sp 9p
.RT
.PP
Bit 3 of the first octet should be set to 1 with all other bits set to
0 to indicate the telex SFU interworking service.
.PP
All other codings are for further study.
.RT
.sp 1P
.LP
10.3.2.25.5\ \fIAll other mandatory parameters\fR
.sp 9p
.RT
.PP
In accordance with Recommendation S.62.
.RT
.LP
10.3.2.26\ Assignment of coding for the identifiers contained in the control
text of the control document is as follows:
.sp 1P
.LP
10.3.2.26.1\ \fIMXU type identity\fR
.sp 9p
.RT
.PP
This parameter is a binary coded field of fixed length of one octet identifying
the MXU type as given in Table\ 6/U.82.
.PP
The hexadecimal representation of these octets is in accordance
with Table 2/U.82.
.PP
All other binary values are reserved for future
standardization.
.bp
.RT
.ce
\fBH.T. [T7.82]\fR
.ce
TABLE\ 6/U.82
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(108p) | cw(72p) .
MXU type     {
Bit:\ \ 8\ 7\ 6\ 5\ 4\ 3\ 2\ 1
 }
_
.T&
lw(108p) | cw(72p) .
Text transfer (TT)     {
Bit:\ \
0\ 0\ 0\ 0\ 0\ 0\ 0\ 1
 }
.T&
lw(108p) | cw(72p) .
Delivery notification (DN)     {
Bit:\ \
0\ 0\ 0\ 1\ 0\ 0\ 0\ 1
 }
.T&
lw(108p) | cw(72p) .
 {
Non\(hydelivery notification (NDN)
 }     {
Bit:\ \
0\ 0\ 0\ 1\ 0\ 0\ 1\ 0
 }
.T&
lw(108p) | cw(72p) .
 {
Combined delivery/non\(hydelivery notification (CN)
 }     {
Bit:\ \
0\ 0\ 0\ 1\ 0\ 0\ 1\ 1
 }
.T&
lw(108p) | cw(72p) .
Status request (SRQ)     {
Bit:\ \
0\ 0\ 1\ 0\ 0\ 0\ 0\ 1
 }
.T&
lw(108p) | cw(72p) .
Status report (SRPT)     {
Bit:\ \
0\ 0\ 1\ 0\ 0\ 0\ 1\ 0
 }
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 6/U.82[T7.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
10.3.2.26.2\ \fIMessage identity\fR
.sp 9p
.RT
.PP
A sequence of graphic characters as defined in \(sc 8.
.RT
.sp 1P
.LP
10.3.2.26.3\ \fIDestination telex SFU identity\fR
.sp 9p
.RT
.PP
A sequence of graphic characters as defined in \(sc 8.
.RT
.sp 1P
.LP
10.3.2.26.4\ \fITransit identities\fR
.sp 9p
.RT
.PP
The use of this parameter is for further study.
.RT
.sp 1P
.LP
10.3.2.26.5\ \fIMessage code indicator\fR
.sp 9p
.RT
.PP
A binary encoded field of fixed length of one octet as in
Table\ 7/U.82.
.PP
All other binary values are reserved for future standardization.
.RT
.ce
\fBH.T. [T8.82]\fR
.ce
TABLE\ 7/U.82
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(72p) | cw(72p) .
     {
Bit:\ \ 8\ 7\ 6\ 5\ 4\ 3\ 2\ 1
 }
_
.T&
cw(72p) | cw(72p) .
ITA No. 2     {
Bit:\ \
0\ 0\ 0\ 0\ 0\ 0\ 0\ 0
 }
.T&
cw(72p) | cw(72p) .
IA No. 5     {
Bit:\ \
0\ 0\ 0\ 0\ 0\ 0\ 0\ 1
 }
.T&
cw(72p) | cw(72p) .
S.61     {
Bit:\ \
0\ 0\ 0\ 0\ 0\ 0\ 1\ 0
 }
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 7/U.82 [T8.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
10.3.2.27\ \fIService Interworking Identifier\fR \v'3p'
.sp 9p
.RT
.LP
10.3.2.27.1\ Coding of the interworking identifier is for further study.
.LP
10.3.2.28\ A formal definition of telex SFU MXUs and the field coding is
shown in Annex A.
.sp 1P
.LP
10.4
    \fIUse of the \fR \fIpublic switched telephone network\fR \v'3p'
.sp 9p
.RT
.PP
10.4.1
Connection between SFUs should be automatically established using normal
telephone procedures.
.PP
10.4.2
Following call establishment the procedures should be as defined in \(sc\
10.3 for PSDNs but using the data transfer phase of
Recommendation\ X.25.
.PP
10.4.3
The normal mode of operation should be full duplex at 2400 bit/s using
LAPX or level 2 of Recommendation\ X.75.
.bp
.PP
10.4.4
Exceptionally Administrations may agree bilaterally to operate
using half duplex and/or at speeds other than 2400 bit/s.
.sp 1P
.LP
10.5
    \fIUse of medium speed direct synchronous circuit\fR \v'3p'
.sp 9p
.RT
.PP
10.5.1
The procedures should be as defined in \(sc\ 10.3.2 for PSDNs
but using the call set\(hyup phase.
.PP
10.5.2
The normal mode of operation should be full duplex using LAPX or level
2 of Recommendation X.75.
.PP
10.5.3
Links between telex SFUs can be used for multiple session and
bothway working by means of a number of logical channels.
.ce 1000
ANNEX\ A
.ce 0
.ce 1000
(to Recommendation U.82)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExamples of field coding and content\fR
.sp 1P
.RT
.ce 0
.ce 1000
\fBof MXUs for \fR \fBinterconnection of telex SFUs\fR
.ce 0
.ce 1000
\fBwhen using the synchronous data network procedures\fR
.ce 0
.sp 2P
.LP
A.1
    \fIIntroduction\fR
.sp 1P
.RT
.PP
This annex specifies the structure and coding of MXUs using the
notation defined in Recommendation\ X.409.
.PP
This structure should be used when telex SFUs are interconnected with each
other using the synchronous data network procedures described in
\(sc\ 10.3.2.
.PP
A number of data types that appear in the formal definition of MXUs
are described in more detail in the following paragraphs.
.PP
The formal definition of MXUs is shown in \(sc A.3 and examples of the
coding are shown in
Figures\ A\(hy1/U.82 to A\(hy4/U.82.
.RT
.sp 1P
.LP
A.2
    \fIDescription of data types\fR
.sp 9p
.RT
.PP
In general the data types are described in \(sc\ 9. Certain data types
are described below to provide clarification on format.
.RT
.sp 1P
.LP
A.2.1
    \fIType identity\fR
.sp 9p
.RT
.PP
The MXU type is identified by a type number coded in accordance
with Table\ 2/U.82.
.RT
.LP
\fBTypeIdentity\fR     ::=
    [APPLICATION 3] IMPLICIT INTEGE {
.LP
\fBTT\fR (1),\fBDN\fR (17),\fBND\fR (18),\fBCN\fR (19),\fBSRQ\fR (33),\fBSRPT\fR
(34 }
.LP
where
.LP
    TT
    Text transfer
.LP
    DN
    Delivery notification
.LP
    ND
    Non\(hydelivery notification
.LP
    CN
    Combined delivery/non\(hydelivery notification
.LP
    SRQ
    Status request
.LP
    SRPT
    Status report
.sp 1P
.LP
A.2.2
    \fIMessage identity\fR
.sp 9p
.RT
.PP
The message identity is described in \(sc\ 9.2.
.RT
.LP
\fBMessageIdentity\fR     ::=
    [APPLICATION 4] IMPLICIT SEQUENC {
.LP
    \fBorigCountryRef\fR     NumericString,
.LP
    \fBorigSFURef\fR     NumericString,
.LP
    \fBmessagesSerialNumber\fR     NumericString,
.LP
    \fBorigTime\fR     DateandTim }
.bp
.PP
The originating country reference is the 2 or 3 digits F.69
country code.
.PP
The originating SFU reference is a 4 character numeric code.
.PP
Message serial number is a 6 digit number.
.PP
The originating time is defined as a date and time type and represents
the local time at the originating telex SFU.
.RT
.LP
\fBOrigTime\fR     ::=
    DateandTime
.LP
\fBDateandTime\fR     ::=
    [UNIVERSAL 24] IMPLICIT IA5String
.PP
Thus an originating (local) time of 12.22\ PM on 9\ May\ 1983 which is
represented by the value \*Q8305091222\*U can be encoded as:
.LP
    DateandTime
    Length
    \ \ \ \ \ \ \ Contents
    \ \ 18
     | A
    38333035303931323232
.LP
    \ \ \ \ 16
     |  \ 16
    \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ 16
.sp 1P
.LP
A.2.3
    \fIMessage code indicador\fR
.sp 9p
.RT
.PP
The message code indicator describes the coding of the message text contained
in the MXU message block and can be ITA2, IA5 or S.61.
.RT
.LP
\fBMessageCodeIndicator\fR     ::=
    [APPLICATION 6] IMPLICIT INTEGE {
.LP
ITA(0),IA5(1),S61(2 }
.PP
It should be noted that the message code indicator only refers to the coding
of the MXU message block and is not applicable to any other data
types. Although the text coding is also described in the UMXU message block
structure (\(sc\ A.2.4) this indicator is retained for completeness in the
structure of an MXU Header.
.sp 1P
.LP
A.2.4
    \fIUMXU message block\fR
.sp 9p
.RT
.PP
The \fBUMXU\fR message block contains the message text received from
the subscriber and can be coded in ITA2, IA5 or S.61. The coding must be in
accordance with the message code indicator.
.RT
.LP
\fBUMXUMessageBlock\fR     ::=
    [APPLICATION 1] CHOIC {
.LP
\fBITA2String,\fR
.LP
[0] IMPLICIT S61String
.LP
[1] IMPLICIT IA5Strin }
.sp 1P
.LP
A.2.5
    \fIITA2 string\fR
.sp 9p
.RT
.PP
An ITA2 String represents an ordered set of zero or more characters chosen
from the set defined by Recommendation\ F.1 in Table\ 1/F.1.
.PP
The ITA2 String is formally defined below. Each octet contains a
single 5\ unit code. Bits\ 8\(hy6 of each octet are zero and bits\ 5\(hy1
correspond
to element numbers\ 5\(hy1 using the F1 element numbering convention.
.RT
.LP
\fBITA2String\fR     ::
    [APPLICATION 7] IMPLICIT OCTET STRING
.sp 1P
.LP
A.2.6
    \fIDelivery information\fR
.sp 9p
.RT
.PP
The delivery information contains one data type, delivery address, that
will always be present. The remaining data types are optional in the sense
that they will be present if and only if the originating SFU has been supplied
with the information.
.RT
.LP
\fBDeliveryInformation\fR     ::=
    SEQUENC {
.LP
\fBdeliveryAddress\fR [0] IMPLICIT NumericString,
.LP
\fBexpectedAnswerback\fR [1] IMPLICIT IA5String OPTIONAL,
.LP
\fBattentionInformation\fR [2] IMPLICIT IA5String OPTIONAL,
.LP
\fBdelayIndication\fR [3] IMPLICIT IA5String OPTIONA }
.PP
The delivery address is the called international telex address in the format
of the F.69 country code and national number.
.PP
The format of the expected answerback and attention information should
remain as provided by the calling subscriber.
.bp
.PP
The delay indication, when present, describes the type of delivery
delay required. The format of this field should be:
.RT
.LP
    a)
    D if the calling subscriber leaves the period of delay to
the discretion of the Administration providing the SFU service,
.LP
    b)
    DXY where XY are numeric characters which specify the
minimum desired delay in hours from 01\(hy23.
.LP
    c)
    LXY where XY are numeric characters (01\(hy24) which specify
the maximum time limit for delivering the message to the
address.
.sp 1P
.LP
A.2.7
    \fISMXU message block\fR
.sp 9p
.RT
.PP
The data values contained in the octets of both the notification
and status report \fISMXU\fR message block and the status request \fISMXU\fR
message
block should be coded in accordance with the message code indicator described
in \(sc\ A.2.4.
.RT
.sp 1P
.LP
A.2.8
    \fINotification and status report SMXU message block\fR
.sp 9p
.RT
.PP
The notifications and status reports provide information about the delivery
status of messages to called addresses. The optional data types will be
present if and only if the SFU transmitting the SMXU message block has
the required information.
.RT
.LP
\fBNotificationandStatusReportSMXUMessageBlock\fR     ::=
    [APPLICATION 8
IMPLICIT SEQUENCE OF SEQUENC {
.LP
[0] IMPLICIT \fBStatus\fR ,
.LP
[1] IMPLICIT \fBCalledAddress,\fR
.LP
[2] IMPLICIT \fBAnswerback\fR OPTIONAL,
.LP
[3] IMPLICIT \fBLastAttemptTime\fR OPTIONAL,
.LP
CHOICE [4] IMPLICIT \fBReason\fR ,
.LP
[5] IMPLICIT \fBChargeableDuration\fR OPTIONA }
.sp 1P
.LP
A.2.9
    \fILast attempt time\fR
.sp 9p
.RT
.PP
The last attempt time represents a time of day local to the SFU
which has the responsiblity for delivering the message. The format of the
last attempt time is a string of characters YYMMDDHHNN,
.RT
.LP
where
.LP
    YY represents two numeric characters indicating the year
.LP
    MM represents two numeric characters indicating the month
.LP
    DD represents two numeric characters indicating the day
.LP
    HH represents two numeric characters indicating the hour
.LP
    NN represents two numeric characters indicating the minute
.LP
\fBLastAttemptTime\fR     ::=
    [APPLICATION 10] IMPLICIT OCTET STRING
.PP
The coding of the octet string should be in accordance with the
message code indicator described
in \(sc\ A.2.4.
.sp 1P
.LP
A.2.10
    \fIReason\fR
.sp 9p
.RT
.PP
The reason indicates why a delivery attempt has failed. The reason is a
string of characters forming the service code that should be returned to
the subscriber.
.RT
.LP
\fBReason\fR     ::=
    [APPLICATION 11] IMPLICIT OCTET STRING
.PP
The coding of the octet string should be in accordance with
message code indicator described in \(sc\ A.2.4.
.sp 1P
.LP
A.2.11
    \fIChargeable duration\fR
.sp 9p
.RT
.PP
The chargeable duration represents the time in minutes and seconds for
which the call should be charged. The chargeable duration is a string of
5\ characters in the format MMM.M, where MMM represents the time in minutes
(0\(hy999) and N represents the time in tenths of minutes (0\(hy9). The
separator is a full stop.
.RT
.LP
\fBChargeableDuration\fR     ::=
    [APPLICATION 14] IMPLICIT OCTET STRING
.PP
The coding of the octet string should be in accordance with the
message code indicator described
in \(sc\ A.2.4.
.bp
.sp 1P
.LP
A.2.12
    \fITransit identities\fR
.sp 9p
.RT
.PP
The transit identities format is subject to further studies on
transit store and forward, but will consist of a sequence of transit identity
information for each transit unit used in the order of call establishment.
.RT
.sp 1P
.LP
A.3
    \fIFormat definition of telex SFU MXUs\fR \v'3p'
.sp 9p
.RT
.LP
\fBMXU\fR     ::=
    CHOIC { 0] IMPLICIT \fBUMXU\fR , [1] IMPLICIT \fBSMXU\fR }
.LP
\fBUMXU\fR     ::=
    SEQUENC { fBUMXUHeader, UMXUMessageBlock\fR }
.LP
\fBUMXUHeader\fR     ::=
    [APPLICATION 0] IMPLICIT SEQUENC {
.LP
\fBTypeIdentity,\fR
.LP
\fBMessageIdentity,\fR
.LP
\fBDestinationSFUIdentity,\fR
.LP
\fBMessageCodeIndicator,\fR
.LP
[0] IMPLICIT SEQUENCE OF \fBDeliveryInformation\fR
.LP
\fBUMXUMessageBlock\fR     ::=
    APPLICATION 1] CHOIC { \fBITA2String,\fR
.LP
[0] IMPLICIT S61String,
.LP
[1] IMPLICIT IA5Strin }
.sp 1P
.ce 1000
\(em\ message text received from subscriber, coded in accordance with message
code indicator\ \(em
.ce 0
.sp 1P
.ce 1000
\(em\ various header information\ \(em
.ce 0
.sp 1P
.LP
\fBTypeIdentity\fR     ::=
    [APPLICATION 3] IMPLICIT INTEGE {
.LP
\fBTT\fR (1),\fBDN\fR (17),\fBND\fR (18),\fBCN\fR (19),\fBSRQ\fR (33),\fBSRPT\fR
(34 }
.LP
\fBMessageIdentity\fR     ::=
    [APPLICATION 4] IMPLICIT SEQUENC {
.LP
    \fBorigCountryRef\fR     NumericString,
.LP
    \fBorigSFURef\fR     NumericString,
.LP
    \fBmessageSerialNumber\fR     NumericString,
.LP
    \fBorigTime\fR     DateandTim }
.LP
\fBDestinationSFUIdentity\fR     ::=
    [APPLICATION 5] IMPLICIT SEQUENC {
.LP
    \fBdestinationCountryRef\fR     NumericString,
.LP
    \fBdestinationSFURef\fR     NumericStrin }
.LP
\fBMessageCodeIndicator\fR     ::=
    [APPLICATION 6] IMPLICIT INTEGE {
.LP
\fBITA2\fR (0),\fBIA5\fR (1),\fBS`1\fR (2 }
.LP
\fBDeliveryInformation\fR     ::=
    SEQUENC {
.LP
\fBdeliveryAddress\fR [0] IMPLICIT NumericString,
.LP
\fBexpectedAnswerback\fR [1] IMPLICIT IA5String OPTIONAL,
.LP
\fBattentionInformation\fR [2] IMPLICIT IA5String OPTIONAL,
.LP
\fBdelayIndication\fR [3] IMPLICIT IA5String OPTIONA }
.LP
\fBITA2String\fR     ::=
    [APPLICATION 7] IMPLICIT OCTET STRING
.LP
\fBSMXU\fR     ::=
    SEQUENC {
.LP
\fBSMXUHeader, MXUMessageBlock\fR }
.LP
\fBSMXUHeader\fR     ::=
    [APPLICATION 2] IMPLICIT SEQUENC {
.LP
\fBTypeIdentity,\fR
.LP
\fBMessageIdentity,\fR
.LP
\fBDestinationSFUIdentity,\fR
.LP
\fBMessageCodeIndicator,\fR
.LP
\fBTransitIdentities\fR OPTIONA }
.LP
\fBSMXUMessageBlock\fR     ::=
    CHOIC {
.LP
\fBNotificationandStatusReportSMXUMessageBlock,\fR
.LP
\fBStatusRequestSMXUMessageBlock\fR }
.LP
\fBNotificationandStatusReportSMXUMessageBlock\fR     ::=
    [APPLICATION 8]
IMPLICIT SEQUENCE OF SEQUENC {
.LP
[0] IMPLICIT \fBStatus\fR ,
.LP
[1] IMPLICIT \fBCalledAddress,\fR
.LP
[2] IMPLICIT \fBAnswerback\fR OPTIONAL,
.LP
[3] IMPLICIT \fBLastAttemptTime\fR OPTIONAL,
.LP
CHOICE [4] IMPLICIT \fBReason,\fR
.LP
[5] IMPLICIT \fBChargeableDuration\fR OPTIONA }
.bp
.LP
\fBStatusRequestSMXUMessageBlock\fR     ::=
    [APPLICATION 9] IMPLICIT SEQUENC {
.LP
\fBrequestType\fR [0] IMPLICIT INTEGE {
.LP
\fBrequestAllAddresses\fR (0),
.LP
\fBrequestNonDeliveryAddresses\fR (1),
.LP
\fBrequestSpecifiedAddresses\fR (2 }
.LP
\fBspecifiedAddresses\fR [1] IMPLICIT \fBAddressList\fR OPTIONA }
.sp 1P
.ce 1000
\(em\ transit identities\ \(em
.ce 0
.sp 1P
.ce 1000
\(em\ transit identities are for further study\ \(em
.ce 0
.sp 1P
.LP
\fBTransitIdentities\fR     ::=
    SEQUENC {
.LP
\fBfirstTrId\fR [0] IMPLICIT NumericString OPTIONAL,
.LP
\fBsecondTrId\fR [1] IMPLICIT NUMERICString OPTIONAL,
.LP
\fBthirdTrId\fR [2] IMPLICIT NumericString OPTIONAL,
.LP
\fBfourthTrId\fR [3] IMPLICIT NumericString OPTIONAL,
.LP
\fBfifthTrId\fR [4] IMPLICIT NumericString OPTIONA }
.sp 1P
.ce 1000
\ \(emSMXU Message Block Information\ \(em
.ce 0
.sp 1P
.ce 1000
\(em\ all octets are coded in accordance with the message code indicator\ \(em
.ce 0
.sp 1P
.LP
\fBStatus\fR     ::
    INTEGE { \fBdelivery\fR (0), \fBnonDelivery\fR (1 }
.LP
\fBCalledAddress\fR     ::=
    OCTET STRING
.sp 1P
.ce 1000
\(em\ called address is restricted to numeric characters\ \(em
.ce 0
.sp 1P
.LP
\fBAnswerback\fR     ::=
    OCTET STRING
.LP
\fBLastAttemptTime\fR     ::=
    [APPLICATION 10] IMPLICIT OCTET STRING
.LP
\fBReason\fR     ::=
    [APPLICATION 11] IMPLICIT OCTET STRING
.LP
\fBChargeableDuration\fR     ::=
    [APPLICATION 12] IMPLICIT OCTET STRING
.LP
\fBAddressList\fR     ::=
    SET { pecifiedAddress IMPLICIT OCTET STRIN }
.LP
.rs
.sp 29P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy1/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy2/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy3/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy4/U.82, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce 1000
APPENDIX\ I
.ce 0
.sp 1P
.ce 1000
(to Recommendation U.82)
.sp 9p
.RT
.ce 0
.sp 1P
.ce 1000
\fBExamples of field coding and content of MXUs\fR
.sp 1P
.RT
.ce 0
.ce 1000
\fBfor interconnection of telex SFUs when\fR
.ce 0
.ce 1000
\fBusing the telex network, direct circuits and circuit\fR
.ce 0
.sp 1P
.ce 1000
\fBswitched data networks using asynchronous transmission\fR
.ce 0
.sp 1P
.LP
.sp 2
.LP
.rs
.sp 27P
.ad r
\fBCuadro, (UTMU\(hyTT) [T9.92], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.bp
.LP
.rs
.sp 23P
.ad r
\fBCuadro, (UTMS\(hyNE) [T10.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
\fR .rs
.sp 23P
.ad r
\fBCuadro (UTMS\(hyNNE) [T11.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 29P
.ad r
\fBCuadro (UTMS\(hyCN) [T12.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
\fR .rs
.sp 20P
.ad r
\fBCuadro (UTMS\(hyPE) [T13.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
\fR
.LP
.rs
.sp 28P
.ad r
\fBCuadro (UTMS\(hyIE) [T14.82], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 27P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.LP
\fR
.LP
\fBMONTAGE:\fR PAGE ... = PAGE BLANCHE
.sp 1P
.RT
.LP
.bp
.sp 1P
.ce 1000
SECTION\ 9
.ce 0
.sp 1P
.ce 1000
(Reserved)
.sp 1P
.RT
.ce 0
.sp 1P
.ce 1000
SECTION\ 10
.EF '%    Fascicule\ VII.2''
.OF '''Fascicule\ VII.2    %'
.ce 0
.sp 1P
.ce 1000
(Reserved)
.sp 1P
.RT
.ce 0
.sp 1P
.ce 1000
SECTION\ 11
.ce 0
.sp 1P
.ce 1000
(Reserved)
.sp 1P
.RT
.ce 0
.sp 1P
.ce 1000
SECTION\ 12
.ce 0
.sp 1P
.ce 1000
(Reserved)
.sp 1P
.RT
.ce 0
.sp 1P
.LP
.rs
.sp 3P
.ad r
Blanc
.ad b
.RT
.LP
.bp